HTTP and API monitoring
Configure a check as flexibly as a regular request and make sure it works before you save it.
The task
A website and API must respond not just with a 200 code but correctly: with authentication, the right headers and in reasonable time. Writing separate scripts for this and keeping them in cron is slow and unreliable.
How it is solved
An HTTP monitor is built like a request: method, URL, parameters, headers, body and authentication. A test run uses the same executor as the production check but does not count toward uptime statistics. If you already have an API description, monitors can be created by import.
What is included
- Authentication: Bearer, Basic, API key and OAuth2 client credentials
- Request body in JSON, text, form-urlencoded and multipart
- Following redirects with a limit on their number
- Import from OpenAPI 3, Swagger 2 and Postman v2.1 collections
- Variables and secrets at the business, product, environment, resource or monitor level
- A record of the sent request with masked secrets
- Response time broken down by phase: DNS, connection, TLS, waiting, download
Limitations
- The minimum check interval and the number of monitors are set by the plan.
- A check cannot reach internal and service addresses: private agents exist for those.
Questions about this feature
Will a test run affect uptime statistics?
No. The test uses the same executor as the production check, but its result does not go into the uptime history and does not open alerts.
Where are authentication passwords and tokens stored?
Secrets are stored encrypted, are not shown again after saving and are masked in the stored request and response.
Can I move checks over from a Postman collection?
Yes. Import accepts OpenAPI 3, Swagger 2 and Postman v2.1 and creates monitors for the selected requests.
Where it helps
Other features
All featuresCheck your services today
The free plan includes checks, a status page and a team of up to three people. The setup wizard takes you from a product to the first notification.