Updated 2026-06-15
An HTTP check requests a URL on its schedule and evaluates the response. It's the right check type for a website, an API endpoint, or anything else reachable over HTTP or HTTPS.
What it evaluates
- Status code — defaults to expecting
200–299; you can set a specific status code or list of acceptable codes instead. - Keyword match — optionally require the response body to contain a
string (
mustContain), or fail if it contains one (mustNotContain) — useful for catching a page that returns 200 but renders an error state. - TLS certificate — for
https://targets, the certificate is verified as part of the check by default (verifyTls); certificate expiry is also tracked and can warn you ahead of time — see SSL certificate checks.
Configuration options
- Method — the HTTP method to send.
- Headers and request body — for APIs that need specific headers or a POST body.
- Basic auth — username/password, encrypted at rest.
- Follow redirects — up to 5 hops.
- Timeout — up to 30 seconds (10 seconds by default).
- IP version — auto, IPv4-only, or IPv6-only.
When to use it
Anything served over HTTP or HTTPS: a marketing site, a customer-facing app, a health-check endpoint, an internal API. If you only need to know whether a port accepts connections (no HTTP semantics), a TCP check is a better fit.
A single failed HTTP request doesn't open an incident on its own — see How multi-region confirmation works for how Status tells a real outage apart from one region's blip.