Checks run from US East, US West, Europe and Asia. One region seeing a timeout is usually a route problem between that region and you; three regions seeing it is an outage. You set how many have to fail before anyone is woken up.
API health check
https://api.example.com/health
99.98%
90-day uptime
Probe regions
asia: probe unreachable — excluded from consensus, no alert raised
Per-region latency, and an errored probe shown amber — excluded, not counted against you.
Almost every uptime tool models a check as up or down. That is one state short, and the missing one is the cause of most false alarms in the category.
Errored regions are excluded from consensus, and the failing-region threshold is clamped to the regions that actually reported. If every region errors, the check is skipped outright — no result row, no alert, no state change, and the last-checked timestamp is deliberately left alone so it retries on the next tick.
This is not a hypothetical. Our probe hosting provider suspended the account the probes ran on, and every probe in every region began returning a billing error to every request.
A two-state system reads that as every monitored site on the platform is down. It opens an incident for each one, pages the on-call engineer for each one, and spends the SMS and voice allowance telling customers their perfectly healthy sites are offline — during an event they cannot do anything about, because the fault is ours.
The three-state rule is what stopped that. Every region errored, the all-regions-failed guard fired, and Atlas wrote nothing and paged nobody. We moved the probes to dedicated infrastructure in four separate regions and kept the rule.
The point
Regional monitoring is easy to claim and easy to fake — several platforms run “multi-region” checks that all execute wherever the request happened to land, then label the results by region anyway. Ours run as separate services in separate regions, and the latency numbers prove it: the same target returns around 80ms from US East and just over a second from Asia.
If a page is slow for customers on one continent and fine everywhere else, that is visible as a latency chart rather than a support ticket.
Every check keeps 90 days of availability, drawn as a per-day bar with the downtime events behind it. Uptime percentages are computed on your calendar, in the timezone set on your account — an evening outage belongs to the evening it happened, not to whichever UTC day it fell into.
The same history is what a public status page publishes, so the number your customers see is the number you see.