Updated 2026-09-29
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 — by default any
2xxor3xx(300–308) response counts as up. Follow redirects is on by default (up to 5 hops), so the check judges the FINAL response after following any redirect chain, not the redirect itself. Turn it off (set it to 0 hops) if you specifically want to monitor the redirect response, or 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. Matching is case-sensitive and covers the first 512 KB of the body. - 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 — GET, HEAD, POST, PUT, PATCH, DELETE or OPTIONS.
- Headers and request body — for APIs that need specific headers or a POST body. Up to 20 headers and a body up to 8 KB; header values are encrypted at rest.
- Basic auth — username/password, encrypted at rest.
- Follow redirects — up to 5 hops.
- Timeout — up to 15 seconds (10 seconds by default).
- IP version — auto, IPv4-only, or IPv6-only.
- Target without a scheme — a target without
http://orhttps://is checked over HTTPS.
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.