Partial outages

Here is an uncomfortable fact about every uptime monitor on the internet, this one included: It requests a page and reports whether the page came back. That is a genuinely useful measurement, and it is blind to the majority of what people experience as an outage.

A social network whose feed will not load still serves a home page. A bank whose transfers are failing still returns its marketing site in 300 milliseconds. A messaging app whose delivery pipeline has stalled still answers a request for its landing page. In every one of those cases the automated verdict is "up", and in every one of them the service is unusable.

The four shapes of partial failure

Regional

Large services run in many locations and route you to the nearest one. When one region has trouble, the people routed to it are completely cut off while everyone else notices nothing. A monitor checking from a single place sees either a total outage or nothing at all, depending on which side of the boundary it sits.

This is the single most common reason for the frustrating exchange where a company says everything is fine and thousands of people are certain it is not. Both are describing their own accurate observation of different regions. Games with regional shards make this explicit - EUW can be completely unavailable while NA is untouched - But the same thing happens invisibly at most consumer services.

Platform-specific

The website and the mobile apps talk to different endpoints, often through different gateways, sometimes maintained by different teams. An app release can break for every user on one operating system while the web version is perfectly healthy, and nothing on the web side will register it.

If a service works in a browser but not in its app, that is almost never a platform outage. It is a client problem - A bad release, a stale token, a cached configuration - And the fix is usually local.

Feature-specific

Modern services are dozens of independent subsystems assembled into one interface. Slack's status page lists messaging, notifications, huddles, files, search, apps and connections separately for exactly this reason, and in practice only one or two are ever affected at a time.

The user-facing result is that "Slack is down" can mean six different things. Messages send but notifications stop. Files will not upload while chat is fine. Search returns nothing in a workspace that is otherwise healthy. Each has a different cause, a different team fixing it, and a different duration.

Account-specific

The loneliest category. Your account is rate limited, flagged, mid-migration, or holding a session that has gone bad. Nothing is down for anyone else, no monitor will ever see it, and no report volume will corroborate it. Signing out entirely and back in resolves a surprising share of these.

Why the reports chart exists

This is the reason a site like this shows crowd-sourced reports next to its own measurements instead of choosing one. The two methods fail in opposite directions.

An automated check is precise, repeatable and narrow. It tells you something true about one URL from one place, and nothing about anything else. A crowd is imprecise, unverifiable and broad. It notices login failures, app breakage, regional problems and feature-level faults immediately, because those are what people actually experience - And it also produces a constant background of reports that mean nothing.

Read together, they resolve each other's blind spots. When our check succeeds and reports are at their normal level, the service is almost certainly fine. When the check succeeds and reports are three times the normal rate, something is broken that the check cannot see, and the problem breakdown on the page usually says what. That combination is the most informative state a status page can be in, which is why it gets its own status word here rather than being rounded down to "up".

Reading the symptom

The symptom you can describe narrows the subsystem faster than any tool.

Reading is nearly always more resilient than writing, because reads can be served from a cache and writes cannot. A service that lets you browse but not post is not half broken - It is a service whose write path has failed, and the read path is running on cached data that will itself go stale.

Why companies are slow to acknowledge these

Not, usually, evasion. A partial failure is genuinely hard to detect from inside. Aggregate error rates can stay within normal bounds while one region, one platform or one feature is completely broken, because the affected slice is small relative to global traffic. The company's own dashboards look healthy in exactly the same way an external monitor does.

There is also an institutional threshold. Declaring an incident has consequences - It pages people, it triggers communication, and it may have contractual implications. Teams are reasonably reluctant to do it until they are confident, which means user reports lead official acknowledgement in almost every partial outage. That gap is typically tens of minutes and occasionally hours.

What to do

Work out which subsystem is broken, using the table above. Then check whether the provider's status page lists that subsystem separately - The good ones do, and a component showing degraded when the overall banner is green is exactly the confirmation you are looking for.

Then stop trying. A partial outage will not be fixed by clearing your cache, and the one thing you can usefully do is report what you are seeing, because a specific description of a specific broken feature is worth considerably more than one more person saying it is down.