What counts as "down"?

An uptime check fails when the target returns a timeout, a connection error, or a response outside the expected range — by default, anything that isn't a 2xx or 3xx HTTP status.

We confirm before we page you

A single failed check is rarely a real outage — networks blip, and a momentary timeout from one vantage point means little. So we confirm first:

• From a single region, we require two consecutive failed checks.
• From multiple regions, we declare an outage only when at least two of three regions agree — each having failed two consecutive checks.

That quorum is the whole point: one flaky network path between us and your server should never wake you at 3am, but a genuine outage that several regions can see, will.

Recovery, too

The moment the target passes again, you get a recovery alert — so a closed incident doesn't stay open in your head, and your timeline shows exactly how long it lasted.

Make "up" mean what you want

You can tighten the definition per monitor:

• set an expected status range (e.g. 200-299, or 200,301),
• require a keyword to be present in the response body (or to be absent),
• send a specific method, headers and body so the check exercises a real code path,
• flag slow-but-working responses with a degraded threshold (see regions and intervals).

A check that returns 200 but is missing the keyword you expect counts as down — which is often exactly what you want for catching a broken deploy that still serves a page.