Most large services do not fail everywhere at once. They fail in one region, one edge location, or for the fraction of users whose DNS happens to point at a broken cluster. Distinguishing that from a global outage changes what you should do about it, and it is harder than it sounds.
Why regional outages happen at all ¶
A modern service is not one machine. Requests are steered to whichever copy is nearest by three mechanisms, each of which can fail independently for a subset of users:
- Anycast and CDN edge nodes: the same address is announced from many locations and you reach the closest. One unhealthy point of presence affects only the users routed to it.
- Geo-aware DNS: the resolver returns different addresses depending on where the query came from. A bad record in one geography breaks that geography.
- BGP routing: a withdrawn or hijacked route makes a service unreachable from some networks while others are untouched.
Add regional cloud dependencies on top. When one cloud region degrades, every service anchored there degrades with it, which is the pattern in our cloud cascade field guide.
The honest limitation of any single check ¶
We should be direct about this, because it is the thing most outage tools quietly gloss over. Our four probe methods differ by HTTP version, TLS strictness, request verb and User-Agent. They do not differ by geography. They all leave the same infrastructure.
That is genuinely useful for a different question, which is whether a site is behaving inconsistently by request shape. But it means a single check from us proves the site is reachable from where we are. Any tool claiming to prove a global outage from one vantage point is overstating what it measured, and we would rather say "reachable from our probes" than imply more.
This is also why we mark a down verdict as unconfirmed unless independent vantage points agree. An outage claim is a statement about other people's experience, and it should require evidence about other people.
Evidence that actually distinguishes regional from global ¶
- Your own second path. Mobile data uses a different network and often different resolvers. If the site works there and not on your Wi-Fi, no regional outage is involved at all.
- A different DNS resolver. Query
1.1.1.1and8.8.8.8and compare. Different addresses for the same name means geo-aware DNS is steering, and one of those clusters may be the broken one. - A VPN exit in another country. The most direct test available to an individual. Works elsewhere, fails at home: regional. See the VPN guide for the ways this test misleads.
- The vendor's own status page, read sceptically. They lag, and they under-report partial failures. Anatomy of a website outage covers why.
- Independent probes. Our live outages page reports what we measured and when, with the method breakdown, so you can judge the evidence rather than take a verdict.
What the shape of the failure suggests ¶
- Some requests work, some fail, from the same machine, seconds apart. Load balancing across a partly unhealthy pool. Not regional; partial.
- Consistently broken for you, fine over a VPN. Regional, or your ISP's path.
- The address you resolve differs from the one a public resolver returns. DNS steering, and worth capturing before it changes.
- Everything fails everywhere, including the status page. Global, and usually short.
What to do once you know ¶
If it is regional, a VPN or a different resolver is often a genuine workaround, and the report worth filing names your region and resolver. If it is global, there is nothing to work around and the only useful action is to watch the incident. Either way, note the time and the failure mode: an incident report with a timestamp and a method breakdown is worth ten that say "it is down".
What it looks like in the numbers ¶
Regional failures have a shape that global ones do not, and you can see it without special tooling.
- Latency that jumps rather than degrades. A clean failover to a distant region shows as a step change, 40ms to 300ms, with everything still working. Nobody will announce this, and it is often the only visible sign.
- Errors that alternate. Refresh five times: three succeed, two fail. That is a load balancer spreading requests across a partly unhealthy pool, and it means part of the fleet is broken rather than a whole region.
- A traceroute that dies at the same hop. Repeat it. A consistent stopping point is a routing problem; a different one each time is congestion or rate-limited ICMP, which is normal and means nothing.
Use traceroute example.com on macOS and Linux, tracert on Windows. Compare on Wi-Fi and on mobile data: the hop where the two paths diverge is where your ISP hands off, and a failure before that point is squarely theirs.
Capture it before it resolves ¶
Regional incidents are frequently over within the hour and are almost never acknowledged afterwards, which makes them impossible to argue about later unless you wrote something down. Worth capturing while it is happening:
- The address the hostname resolves to for you, and from a public resolver.
- A timestamp with a timezone.
- Your region and ISP.
- The failure mode, and whether a VPN exit elsewhere changes it.
Those four fields are what turn "it was broken this morning" into a report an operator can act on, and they take under a minute to collect.