Your website is down from some locations but not others. A customer in Sydney sends a screenshot of a timeout; you open the same URL from your desk and it loads in 300 ms. Your monitoring says everything is fine. Both of you are telling the truth.
This is not a rare corner case. It is a routine consequence of how the internet is built: the path from a user to your server is different for every user, and most of that path belongs to someone else. When we measured the same 190 services from four regions in the same hour for One internet, four speeds, median response times between regions differed by more than 2x, and that was on a quiet day with nothing broken. When something is actually broken, the gap is not 2x slower. It is up in one place and down in another.
Here are the five mechanisms that do it, roughly in order of how often we see them, and then a triage order for working out which one you have.
1. DNS: different resolvers, different answers
DNS is a distributed cache, and caches disagree. If you changed a record recently, resolvers that cached the old answer keep serving it until the TTL runs out; users behind those resolvers reach the old address, or nothing. Geo-DNS setups do this on purpose, answering with a different IP depending on where the query comes from, which means a broken record for one geography breaks exactly that geography and nowhere else.
The tell: the site fails with a DNS resolution error or connects to the wrong server, and the failure follows the resolver, not the user. The same user on the same laptop often recovers by switching to 1.1.1.1 or 8.8.8.8.
2. CDN and edge: one PoP having a bad day
If you serve through a CDN, users do not connect to your server. They connect to the nearest edge point of presence, and there are hundreds of them. One PoP can be overloaded, misconfigured, or serving a stale error while every other PoP is fine. Your origin is healthy, your monitoring (which probably checks the origin, or checks through one well-behaved PoP) is green, and everyone routed to the bad PoP gets errors.
The tell: failures cluster by city or country, response headers show the CDN (not your origin) generating the error, and the CDN provider's own status page may admit to a regional issue, eventually.
3. Routing: the path between networks broke
Traffic crosses several networks between a user and your server, and the routes are negotiated continuously over BGP. A bad route announcement, a congested exchange point, or a failed link at a transit provider can make your server unreachable from entire networks while the rest of the world connects normally. Neither endpoint is at fault, and neither endpoint can see it: your server is up, the user's connection works, and the road between them is closed.
The tell: connections time out rather than being refused, traceroutes from affected locations die at the same intermediate hop, and it fixes itself without you deploying anything.
4. Your own regional infrastructure
If you run multi-region infrastructure, one region can simply be down: a bad deploy that reached one cluster first, a regional cloud outage, a database replica lagging behind. Load balancers with health checks are supposed to route around this, but a health check that tests too little (a TCP connect, not a real request) will keep sending users into a region that accepts connections and then serves errors.
The tell: the failure boundary matches your own architecture. Users are affected exactly along the line where you split traffic.
5. Deliberate blocking and filtering
Some geographic failures are policy, not fault: a national firewall, an ISP-level block, a corporate proxy, or your own geo-blocking or rate-limiting rules catching more than you meant. From inside the affected network the site is down; from everywhere else nothing is wrong, and nothing ever will be, because nothing is broken.
The tell: the affected set is one country or one organization, it is stable over time, and requests fail in a characteristic way (reset connections, block pages, certificate interception).
The triage order
When the "down for some people" report arrives, work down this list:
- Get one fact from outside your own network. A report from a user plus a check from your desk is two vantage points already, and they disagree, which is information. A free single-shot checker (ours is at /tools/is-it-down, and it makes one fresh server-side request from outside your network path) gives you a third.
- Separate DNS from connectivity. Does the affected location resolve your hostname at all, and to the IP you expect? A wrong or missing answer is mechanism 1, and you can stop here.
- Look at who generated the error. An error page with your CDN's headers is mechanism 2. A timeout with nothing at all is mechanism 3, or a firewall. An error with your own application's fingerprints is mechanism 4, and it is yours to fix.
- Map the affected set against your architecture. If the boundary of who is affected matches how you split traffic (by region, by cluster, by anycast site), the problem is inside your house.
- Only then blame the internet. Routing incidents are real, but they are the explanation of last resort because you can do the least about them. Confirm with traceroutes from an affected network before you write "upstream routing issue" in the incident channel.
Why a single-location monitor cannot see this
Every mechanism above has the same property: the answer to "is it down?" depends on where you ask from. A monitor that checks from one location gets one answer, and whichever answer it gets, it is wrong for part of your users. Worse, the answer is usually "up," because monitoring infrastructure tends to live in well-connected data centers on clean network paths, which is precisely where problems are least likely to be visible.
This is why we built RealUptime Monitor to check from independent regions on every continent we cover and to show each region's reading separately, rather than collapsing them into one number. A regional outage then reads as what it is: three regions green, one red, with the failing region named. The same measurements drive the status page, so during a regional incident your customers in the affected geography see "degraded in Sydney, healthy elsewhere" instead of a green board that contradicts their own screen.
We publish how region disagreement looks in practice across the several hundred public services we track on the outages hub, and the methodology behind those readings is public too. The short version stands on its own, whether or not you use our product: the internet is not one place, so do not measure it from one place.