The outage catalog tracked 195 active services as of 2026-10-05. The count is the least interesting thing about it. What matters is the work behind each row, which is curation, not counting.
Anyone can write a script that pings a thousand homepages and calls the result a status page. We do not think that is honest. We would rather grow slowly than publish a green checkmark that means nothing.
Here is what happens before a service earns a row in the catalog, and how we label what we cannot measure.
What must a service clear to join the catalog?
Every candidate URL must pass a real request before it joins the catalog. It gets a real, unauthenticated GET from our own machine, with the published probe user agent, before it is added. The request is an actual request, not a documentation claim and not "this should work." If the response is not what we expect, the candidate does not go in as-is.
Plenty of well-known names fail that step. Banks, large retailers, and consumer apps often answer an unauthenticated request with a bot challenge page, a CDN or firewall block page, or a geo-block. A candidate like that is left out rather than added with a caveat, because a catalog that counts rows it cannot verify is worse than a smaller one that does not.
Why is a healthy status code not enough?
A status code is not enough because the same code can mean two different things. The harder problem is the services that answer with such a code. A 403 Forbidden can mean "this account is not authorized," or it can mean "a bot-defense product intercepted the request before it reached the service at all." Both look identical on the status line.
For those endpoints we do not trust the code alone. We add an expect: a stated assertion about what a healthy response's body, header, or JSON shape has to look like, checked against up to 256 KB of the actual response.
Without that assertion, declaring a 403 "healthy" would be indistinguishable from declaring a block page healthy. That is exactly the kind of lie a bigger number should never buy.
The same discipline decides which endpoint a service gets probed on at all. A marketing homepage answering 200 mostly proves a CDN is up. Where we can find one, we prefer a real, documented API or auth surface instead:
- Cloudflare's own public IP list endpoint over its homepage.
- Spotify's search API returning a declared-healthy 401 over its landing page.
- Gmail's own mailbox feed answering 401 over a page that only proves a server exists.
The catalog schema calls this the difference between reachability and functional measurement. Every service page says which one it is getting, rather than letting a marketing homepage pass as proof the product works.
Every endpoint's row also states, in plain language, what "down" is allowed to mean for that specific service. That is the down_definition field, written per endpoint rather than assumed. A homepage-only reachability check for an airline is not the same claim as a functional check against a package registry's real API. Pretending otherwise is how a catalog quietly overstates what it knows.
Is blocked the same as down?
No. The vocabulary matters as much as the plumbing. When a probe gets refused or filtered, that is evidence about our own reception, not a confirmed outage. We call that state blocked, never down, and it can never open or close a public incident on its own. A service we cannot honestly measure right now is marked as such. It is not silently promoted to "operational." It is not marked "down" either, because a firewall having opinions about our IP is not the same claim as a vendor's product failing.
What a reading is, and what we correct
A reading is one measurement from one place at one time. We probe from up to ten named regions and publish each region's reading separately, so you can see where a request failed and where it did not, instead of one blended verdict. A reading is not a guarantee about the service, and our own probes are sometimes the thing that is wrong: a region can lose part of its own network path and report failures for services that were answering. When that happens we retract what we published and list it at /outages/corrections.
Free, no account, and the actual demo
The outage tracker is free and has no account, on purpose. The tracker is not a lead-gen gate dressed up as a public good. It uses the same fleet and the same honesty rules that back RealUptime Monitor and RealUptime Status, pointed at services nobody has to sign up to see.
Read the methodology, watch the hub
The full rules, including what we do and do not measure and why a stale reading declares itself stale instead of impersonating a fresh one, are at /outages/methodology. The live board, every service, region by region, is at /outages. Neither page will tell you a service is fine because a homepage answered. Both will tell you when we simply could not check.