If your on-call process treats vendor status pages as a detection mechanism, you are running on a signal that is slower than your users, graded by someone else, and occasionally hosted on the same infrastructure that is failing. We pulled the public incident feeds for two widely used providers on August 25, 2026, and the numbers make the problem concrete: across the 50 most recent incidents Cloudflare has published, spanning August 4 to August 24, exactly one was rated above "minor." Forty two were minor and seven were rated no impact at all.

That is not an accusation of dishonesty. Cloudflare's grading is defensible from where Cloudflare sits. A Durable Objects error spike confined to Hong Kong genuinely is minor against global traffic. The trouble is that your on-call engineer does not serve global traffic. They serve your traffic, and if your workload happens to live in Hong Kong that "minor" incident is a full outage with a green-ish dot next to it.

This post is about why vendor status pages fail as an on-call signal, what the last three weeks of real incident data shows, and what to measure instead so that your pager fires on your users' experience rather than on someone else's severity taxonomy.

What three weeks of status page data actually looks like

Most engineers have a vague sense that status pages undercount. Numbers sharpen it considerably. Both figures below come from the providers' own public JSON incident endpoints, fetched on August 25, 2026. Both feeds return the 50 most recent incidents, so these are floors, not totals.

Cloudflare: 50 incidents in 21 days, one above minor

Between August 4 and August 24, Cloudflare's status page published 50 incidents. The severity breakdown was 42 minor, 7 none, and 1 major. The busiest days carried six separate incidents each. Read the titles and the shape becomes clear: "Increased Errors for Durable Objects in the Hong Kong region," "Network performance issue in Mumbai," "Elevated error rates in Chicago (ORD) region," "Increased HTTP 5xx Errors in Chicago," "Network connectivity issues in Dubai (DXB)."

Almost all of it is regional, partial, and short. Almost none of it would have moved a global availability number enough to justify a louder label. And almost all of it, for the subset of customers routed through the affected metro, was indistinguishable from the service being down.

Anthropic: severity that moves, detail that does not

The Claude status page tells a different story with the same lesson. Its 50 most recent incidents span July 17 to August 24, 2026, and the severity distribution is genuinely varied: 31 minor, 12 major, 4 critical, 3 none. This is a provider that is willing to say "critical" when it means it, which is more than many do.

What it does not give you is a number. The recurring incident titles are "Degraded performance for multiple models" and "Elevated errors for multiple models." Elevated relative to what? Degraded by how much? A model API returning 529 on eight percent of requests and one returning 529 on eighty percent of requests get the same headline. Your retry budget, your queue depth and your user-facing timeout behaviour are wildly different in those two worlds, and the status page will not tell you which one you are in.

One entry from August 14 is worth pausing on, because it is the whole argument in a single line: "Issues reaching status.claude.com." The status page logged an incident about itself being unreachable. Any detection strategy whose first step is "check the vendor's status page" has a dependency on the vendor's status page.

GitHub: nearly eight hours, and the label was never the problem

The counterexample matters too. On August 17, 2026, GitHub.com ran degraded from 13:28 to 21:15 UTC, roughly seven hours and forty seven minutes, with elevated errors across Issues, Pull Requests, the APIs, Actions and Copilot. Nobody had trouble noticing that one. GitHub's retrospective, covered in detail by The Register, described network saturation on load balancers in a Central US facility after an Istio sidecar hit its concurrency limit, with monitoring that watched the host service rather than the sidecar's limit, and a client retry loop that amplified traffic during recovery.

GitHub publishes thorough monthly availability reports, and this one landed within days. That is good practice and it is genuinely useful. It is also, unavoidably, days late. Postmortems are for learning. They are not a detection channel, and no amount of transparency changes that.

Why vendor status pages fail as an on-call signal

Pull those three cases apart and you get five distinct failure modes. They compound.

Severity is graded from the vendor's vantage point

Every provider computes impact against its own denominator: total requests, total customers, total regions. You are a rounding error in that denominator. This is structurally true and no amount of vendor goodwill fixes it. When Cloudflare rates 42 of 50 incidents minor, it is describing the global blast radius honestly. It is not describing yours, and it has no way to.

Regional incidents are globally minor and locally total

Look again at that Cloudflare list. Hong Kong, Singapore, Mumbai, Chicago, Dubai, Indonesia, Phoenix, Los Angeles. Modern infrastructure fails at metro granularity far more often than it fails globally, which is a huge reliability win overall and a detection nightmare for any single customer. The probability that a randomly chosen incident affects you is low. The probability that it destroys your availability when it does affect you is high. Status page severity averages exactly the wrong way for this distribution.

Status pages lag human confirmation

Almost every status page update is gated on a human deciding that the thing is real, is customer visible, and is worth posting. That is minutes at best on a well drilled team, and considerably longer when the incident is ambiguous. Your users start complaining before that. Your error rate moves before that. If the status page is your trigger, you have voluntarily accepted a detection delay you do not control and cannot measure.

Status pages share fate with the thing they describe

Most status pages are hosted independently for exactly this reason, and it still is not a guarantee, as that August 14 entry shows. More subtly, the humans who update the status page are frequently the same humans fighting the incident, and status updates lose that priority contest every time. Silence on a status page is not evidence of health. It is evidence of nothing.

"Elevated errors" is not a number you can alert on

This is the one that bites hardest in practice. Your alerting is built on thresholds: error ratio over five minutes, p99 latency, queue depth, saturation. A status page emits prose. There is no clean mapping from "degraded performance for multiple models" to "page the on-call engineer" or "do not page the on-call engineer," which means every status page update becomes a judgment call made by a tired person at an inconvenient hour.

What to measure instead: dependency SLOs from your own call path

The fix is not complicated, it is just work that tends to get deferred because the vendor appears to be doing it for you. The principle: measure every external dependency from inside your own service, at the point where you call it, and alert on your measurement.

Instrument the client, not the vendor

Wrap every outbound call to a third party in the same telemetry you would demand of an internal service. At minimum, per dependency and per operation, emit request count, error count split by class, and a latency histogram. Errors should be split at least three ways, because the response differs: transport failures such as connection resets and DNS problems, server-side rejections in the 5xx family including capacity signals like 429 and 529, and timeouts you enforced yourself.

That last category is the one teams most often miss. A dependency that answers slowly rather than failing outright will not show up as an error anywhere unless you are counting your own timeouts, and slow is the dominant failure mode for the regional degradation pattern the Cloudflare data is full of.

Pick per-dependency thresholds that map to user harm

Not every dependency deserves the same treatment, and treating them uniformly is how you end up either over-paged or under-protected. A rough tiering that holds up:

Tier one, in the request path with no fallback. Your primary database, your auth provider, your payment processor. Error ratio above roughly two percent sustained for five minutes should page. Users are already seeing it.
Tier one, in the request path with a degraded fallback. A search index that can fall back to a slower query, an AI feature that can return a non-personalised result. Page on fallback rate, not on dependency error rate, because the fallback firing correctly is the system working as designed. Page when fallback exceeds the level your product can absorb.
Tier two, asynchronous with retry. Analytics ingestion, webhook delivery, email. Alert on queue depth and oldest-message age rather than instantaneous error rate. A ten minute outage here is invisible. A two hour one is not.
Tier three, internal tooling only. CI, chat, dashboards. These should notify a channel, never page. They matter enormously during an incident and not at all at 3am on a Sunday.
Any tier, sudden change in shape. A dependency whose latency histogram shifts materially without a matching error rate change is the earliest warning you will get for the "degraded, not down" case.

Synthetic probes for the paths real traffic does not cover

Client instrumentation only sees the calls you actually make. If a code path runs twice an hour, you will find out it is broken up to thirty minutes late. Add lightweight synthetic checks for the operations that matter and are infrequent: OAuth token refresh, a signed upload to object storage, a write to each region you deploy in. Run them from the regions you serve, not just from one place, because the regional pattern in that incident data is the entire point. A synthetic check running only from us-east-1 would have missed nearly every Cloudflare incident in August.

Use the status page as corroboration, never as trigger

Vendor status pages have exactly one good job in this design: confirming attribution once you already know something is wrong. When your dependency SLO burns and the vendor's feed shows an open incident for your region, you have skipped a great deal of internal investigation and can go straight to customer communication and fallback activation. Subscribe to the JSON or Atom feeds, pipe them somewhere visible, and treat every entry as context rather than as an alarm.

Making dependency signals usable where the team already works

Detection is only half of it. The information has to reach a person who can act, with enough context that they do not spend the first ten minutes reconstructing what you already knew. This is where a Slack-native approach earns its keep, because the alternative is an alert in one tool, a status feed in a second, the runbook in a third, and the actual conversation in Slack anyway.

Concretely, the setup that works looks like this. Dependency SLO burn alerts route through your on-call schedule and page the owning team, with the alert payload carrying the dependency name, the affected region, the current error ratio against threshold, and a direct link to the runbook. In parallel, vendor status feed entries post into a dedicated low-noise channel that nobody is paged for but everybody can search. When an incident opens, the responder has both signals in one place: their own measurement, which is authoritative, and the vendor's narrative, which is context.

Pagerly is built around this shape. On-call rotations live in Slack, the on-call user group stays in sync so @oncall always resolves to the right person, alerts route to the right rotation with escalation if nobody acknowledges, and incident channels spin up with the context attached rather than empty. The practical value during a third-party degradation is that the responder never leaves the room where their colleagues are already talking, and the timeline of who saw what and when is captured as a byproduct rather than reconstructed afterwards.

Whatever tooling you use, the properties that matter are the same:

One place to look. Your measurement and the vendor's claim visible side by side, not in two products.
Unambiguous ownership. Every external dependency has a named owning team and a rotation, decided in advance.
Escalation that assumes the first page will be missed. Especially for dependencies that fail at odd hours in regions your primary on-call does not live in.
Runbook attached to the alert. Not linked from a wiki index three clicks away.
A timeline that writes itself. Third-party incidents generate the most contested postmortems, because attribution is disputed. Contemporaneous notes settle it.

A dependency runbook that survives a vague status page

Write one page per tier one dependency. Keep it short enough that a responder reads it rather than skims it. Four sections is usually enough.

Decide ownership before the incident, not during it

The most expensive minutes in a third-party incident are spent deciding whose problem it is. Payment processor degradation: is that the payments team or the platform team? AI provider errors: the feature team that shipped the integration or the infrastructure team that owns the gateway? Write it down. The rule that works is that whoever ships the integration owns the page for it, with platform as escalation. Ambiguity here reliably costs more than any technical decision in the runbook.

Define the degradation lever and who may pull it

For each dependency, name the specific action available: switch to the secondary provider, serve stale cache, disable the feature behind a flag, shed non-essential traffic. Then state explicitly whether the on-call engineer can pull that lever alone at 3am. If the answer is no, you do not have a mitigation, you have a meeting. Most teams discover they have accidentally built the second thing.

Set the retry policy deliberately, and cap it

The GitHub retrospective is the current best example of why this belongs in the runbook rather than in a library default. A client retry loop amplifying traffic during recovery is not an exotic failure, it is the standard one. Every dependency call should have jittered exponential backoff, a hard cap on attempts, and a circuit breaker that opens on sustained failure. Critically, the breaker should stay open long enough for the dependency to actually recover. A breaker with a two second reset window is a retry storm with extra steps. When a provider is returning capacity errors like 429 or 529, retrying harder is the single worst available move, and it is the default behaviour of a surprising number of SDKs.

Draft the customer message before you know the cause

You will be asked for a customer-facing statement long before the vendor tells you anything useful, and possibly before they acknowledge the incident at all. Keep a template that describes impact in your own product's terms without speculating on cause: what is affected, what still works, what the workaround is, when you will update next. Naming the vendor is a judgment call and usually premature until they have posted publicly, but describing your own impact never is. The teams that handle third-party incidents well are almost always the ones that decoupled their communication from the vendor's.

The takeaway

Fifty incidents in twenty one days, one rated above minor. That single statistic is not an indictment of any provider. It is a description of what modern infrastructure failure looks like: frequent, partial, regional and short, distributed across dozens of small events rather than concentrated in a few large ones. Severity labels designed to summarise global impact simply cannot represent that distribution to an individual customer, and they were never intended to.

So stop asking vendor status pages to do a job they are structurally incapable of doing. Instrument your own call paths. Set dependency SLOs that reflect what your users actually feel. Probe from the regions you serve. Route the resulting signal to a named owner with a runbook and a lever they are allowed to pull without waking anyone else up. Then, and only then, read the status page, for the one thing it is genuinely good at: telling you that the problem is not yours to fix.

The vendors will keep publishing. That is a good thing and the transparency is real. Just make sure that by the time the post appears, your team already knew.