What we check
For each service on the outage tracker, we send a single HTTP GET request to a public endpoint from 4 independent regions (US East, US West, Europe, and Asia Pacific) on a fixed schedule. Each check records exactly four things:
- Reachability. Whether a TCP connection and TLS handshake to the endpoint succeeded from that region, within our request timeout.
- HTTP status code. The exact status line returned, if the connection succeeded.
- Latency. Time from request start to receipt of the status line, per region.
- TLS handshake success or failure. A distinct signal from an HTTP-level failure. A TLS failure often points to a network-path or certificate problem rather than an application-level outage.
We follow up to 3 redirects, re-checking each hop against the same safety rules we use for a customer's own monitor before following it. We never read past the status line: response bodies are not downloaded, stored, or inspected. A request that does not receive a response inside our timeout, or that fails at the network or TLS layer, is recorded as down.
What we do not check
This is the complete list of what a status-line GET can honestly support, so it is worth being equally clear about what it cannot:
- The service's actual user-facing experience. A user might see errors on checkout while our probe of the homepage returns a clean response. We check one endpoint, not the whole product.
- Internal service health. Queue depth, database replication lag, or any backend state that is invisible from outside the service is outside what a public GET request can see.
- Anything behind authentication. We do not log in, hold an account with any service on the tracker, or attempt a real transaction. A login page returning a normal response tells us the login surface is reachable, not that authentication or the systems behind it are working correctly.
- Global coverage. We check from 4 regions: US East, US West, Europe, and Asia Pacific. We do not have a Middle East region yet. We say "monitored from 4 regions," never "global" or "worldwide," because that would claim coverage we do not have.
How we read a response
Each service on the tracker has its own declared range of status codes we treat as healthy, since a redirect or a non-200 response can be entirely normal for one service and a genuine problem for another. A response outside that range, a connection failure, or a timeout is recorded as down.
A response of 403 or 429 is recorded separately, as blocked, rather than folded into down. That response tells us about our own request's reception, not necessarily about the service's health: a service can return one of these codes to automated traffic it does not recognize while working normally for everyone else. We show blocked as its own state so a page never overstates what a block actually proves.
A redirect loop, our request bouncing between the same two or three URLs until we give up following it, is also recorded as blocked, not down. A real visitor's browser does not get stuck in the kind of consent or bot-check redirect chain that a request from our probe's network sometimes does, so a loop tells us about how our traffic is being routed, not that the service has failed.
A request that never receives a response before our timeout is usually recorded as down, since a real user would see the same thing: a page that never loads. There is one exception. If the same service has a second endpoint we check, and that second endpoint responded normally in the same round, we record the timed-out endpoint as blocked instead of down. A live sibling reading is evidence that our specific request was filtered, not that the service failed to respond to anyone. Without a healthy second reading to point to, a timeout stays down.
How we identify ourselves
Every request the outage tracker sends carries a plain, honest User-Agent header identifying it as our probe and linking back to this page, so an operator who notices our traffic can see exactly what it is and why. We do not spoof a browser, use a residential proxy, or attempt to get past a challenge page. Some services allowlist declared, self-identifying monitors, which can reduce how often we get blocked. That is a reasonable outcome of being honest about who we are, not something we engineer around.
When our reading and a service's own status page disagree
Where a service publishes its own machine-readable status feed, a service page compares our reading against theirs. When the two disagree, we say so plainly and name both readings rather than asserting either one is correct. A disagreement can mean a partial or user-specific issue our simple check does not exercise, a difference in what each of us is actually probing, or a delay in one side updating. We do not have enough information to resolve that gap from outside, and we do not pretend otherwise.
Why this exists
The outage tracker is a small, honest instrument: it tells you what we observed, when, and from where. It is not a substitute for a service's own status communications, and it is not a claim about anything we cannot actually measure. If you want this same set of checks running against a site you own, with alerting when something changes, you can set that up directly.