"Works for me" is the least useful sentence in incident response, and it is usually true. A large service is not in one state. It is in as many states as it has clusters, edge nodes, feature flags and release cohorts, and two users can sit on opposite sides of any of them.
Seven ways a service is up and down at once ¶
1. Gradual rollouts
Nobody deploys to everyone simultaneously. A new version goes to one per cent, then ten, then half. If it is broken, exactly that fraction of users is broken with it, and everyone else sees a perfectly healthy service. This is by far the most common cause of "only some people".
2. Edge node health
Content is served from the network location closest to you. Yours can be unhealthy while every other one is fine. Two people in the same city can hit different nodes.
3. DNS answers that differ by resolver
Geo-aware DNS hands out different addresses depending on where the query came from, and records propagate at different speeds through different caches. During a migration, some users reach the new infrastructure and some the old for hours. See how long DNS propagation really takes.
4. Feature flags and account state
Features are enabled per account, per organisation, or per plan. A bug behind a flag affects only the accounts that have it. Nothing about the network or the region explains this one, which is why it is so confusing to debug from outside.
5. Sharded data
Large services partition users across database shards. One unhealthy shard takes out the users who live on it and nobody else. Whether you are affected depends on your user ID, which correlates with nothing you can observe.
6. Client version
Desktop app, mobile app, and web all talk to the same backend with different code. An API change that breaks one client leaves the others working. Someone on an older app version can be fine while everyone who updated is broken, or exactly the reverse.
7. Your own path
ISP routing, peering disputes, a bad hop. Genuinely local to a network rather than to a person, but it presents identically. The mobile data test settles this one in ten seconds.
Turning "works for me" into evidence ¶
The disagreement is data if you collect it properly. Ask both parties for:
- Country and ISP, or mobile carrier.
- DNS resolver in use, and the address the hostname resolves to.
- Client, and its version.
- Exact error and how long it took to appear.
- A timestamp with a timezone.
Those five fields turn two contradictory anecdotes into a pattern. Resolved addresses that differ point at DNS or edge. Same address and same error from different networks points at the service. Different client versions point at a release.
What an outage checker can and cannot settle ¶
An independent check adds a vantage point neither of you had, which is worth something: our checker probes with four different request shapes, so it can show that a service answers a browser-shaped request and refuses a plain one, or serves HTTP/1.1 and not HTTP/2. That is the kind of split that produces exactly this argument.
What it cannot do is prove a service is healthy for everyone. No single vantage point can, and we mark our own down verdicts as unconfirmed for that reason. If our probes reach a site your friend cannot, all three of you are telling the truth, and the disagreement itself is the finding. For a worked example on one service, see checking whether Discord is down.
Bisecting a disagreement ¶
When two people disagree about whether a service works, each difference between them is a hypothesis, and most can be tested in seconds. Work through them cheapest first:
- Network. The person who fails switches to mobile data. Fixed? Their network. This eliminates the largest category in one step.
- Client. Try the web version instead of the app, or a different browser. Fixed? Client or profile, and the Incognito test narrows it further.
- Account. Log in as a different user on the same machine, if you can. Fixed? Account state or a feature flag, and nothing about the network was ever relevant.
- Region. A VPN exit near the working person. Fixed? Regional, with the caveats in the VPN guide.
- Resolution. Compare the address each of you resolves. Different? DNS steering or a migration in progress.
Four of those five need no special access and no cooperation from the vendor.
What a useful report looks like ¶
Compare these two, both describing the same incident:
Discord is down for me but fine for my friend.
Voice connect fails for me, desktop app 1.0.9142, UK, resolving gateway to 162.159.x.x. My friend on the same version in Germany resolves a different address and connects fine. Started 19:05 UTC, still failing at 19:40. Web client fails the same way from my network; mobile data works.
The second one contains a diagnosis. It rules out the client, rules out the account, implicates the network path or the edge, and gives an operator two resolved addresses to compare. It took perhaps two minutes to assemble.
When neither of you is wrong ¶
The uncomfortable conclusion of all this is that "is it down" often has no single answer. A service running a broken deployment to ten per cent of users is genuinely down for those users and genuinely up for everyone else, and no amount of checking from outside will produce a verdict that satisfies both. The useful question is not whether it is down; it is what distinguishes the people it is down for.