Poll the model provider's status page, not your coding tool's

At 04:50 UTC on August 24, requests to Claude models started failing. Anthropic opened a major incident on status.claude.com sixteen minutes later. Cursor, which serves those models inside its editor, opened a minor incident forty-eight minutes in. GitHub, which serves them inside Copilot, opened a major incident after two hours and twenty-two minutes. One root cause, three status pages, three different accounts of reality.

That morning was a clean natural experiment in a question most outage tooling never asks: which status page is your status page? Our July fallback guide recommends a status-page pre-check in your circuit breaker — one cheap HTTP call before you burn a retry budget. That advice still stands, but it carried a silent assumption: that the page belonging to the provider you pay describes the outage you are having. If you reach the model through Cursor, GitHub Copilot, or any other layer that resells inference, August 24 is the counterexample.

The timeline, from the pages themselves

Every timestamp below comes from the three public Statuspage APIs — status.claude.com, status.cursor.com, and githubstatus.com, each at /api/v2/incidents.json — and we re-pulled all three before publishing this. The permalinks: Anthropic, Cursor, GitHub.

Time (UTC)	Page	Event
04:50	—	Actual impact begins, per Anthropic's own closing note
05:06	Anthropic	Opens "Elevated errors for multiple models" as major
05:38	Cursor	Opens "Elevated errors for Claude Opus 5" as minor
07:12	GitHub	Opens "Elevated errors on Fable 5 due to upstream provider" as major
07:36	—	Actual impact ends, per Anthropic's closing note
07:58	GitHub	Resolved
08:30	Anthropic	Resolved
08:51	Cursor	Resolved

Three properties of this table are worth keeping after the incident itself is forgotten.

The lag is not uniform, and it is largest where you can least afford it. Counted from actual impact start, the delays were +16 minutes, +48 minutes, and +2 hours 22 minutes. A Copilot user whose agent runs on Fable 5 had failing requests for nearly two and a half hours before githubstatus.com said a word — while the upstream page had been reporting a major incident for most of that time.

Severity describes the vendor's surface, not the fault. Anthropic and GitHub both classified the incident as major. Cursor classified the same root cause as minor. None of them is lying; each page is calibrated to its own product. A severity level is not a property of the outage. It is a property of who is reporting it.

Resolution runs in the wrong order too. GitHub marked its incident resolved at 07:58 — thirty-two minutes before Anthropic did, while the upstream page still read identified. A health check polling GitHub's page got a green light while the provider serving the model was still working the problem. A resolved from the layer in between is a claim about their dashboard, not a receipt that the cause is gone.

There is one more asymmetry, and it is the practical one: Cursor names the upstream, GitHub does not. Cursor's notice says "An upstream Anthropic issue" and links status.claude.com, which tells you exactly where to look next. GitHub's says "the upstream model provider" — no name, no link — and recommends "choosing another model or selecting 'Auto'". Reading only GitHub's page, you cannot even determine which upstream page to open.

Where to point the check instead

The July post's pre-check stays; three things about it change.

First, list the model providers your tools call, not the vendors you invoice. Your Cursor bill goes to Cursor and your Copilot bill goes to GitHub, but the inference comes from Anthropic, OpenAI, Google, or whichever provider backs the model in your picker. Write the mapping down: each tool, each model you use in it, the provider behind that model. For Claude Code on a direct API key the mapping is trivial; for a multi-model editor it is usually three or four upstream pages, and you did not know you depended on all of them.

Second, poll the upstream page for outage detection, and the tool's page only for context. The Statuspage API is identical across hosts, so redirecting the check is a hostname change. For a specific product rather than the whole page, incidents/unresolved.json is more useful than the top-level indicator:

curl -s https://status.claude.com/api/v2/incidents/unresolved.json
curl -s https://status.openai.com/api/v2/incidents/unresolved.json

An empty incidents array means no open incident; anything else gives you the name, impact, and latest update in one call, no auth required.

Third, do not trust the top-level indicator to surface your component. The status.json indicator aggregates the vendor's whole component tree. This morning gave a live demonstration: GitHub had an open critical incident on "Copilot AI Model Providers" while its top-level status.json read minor — "Partially Degraded Service" — because the rest of the tree was healthy. A pre-check that gates on indicator != "none" would have caught it; one that gates on major or worse would have sailed straight into a critical Copilot outage.

This morning ran the experiment in reverse

The mirror case is live as this post is written. At 10:04 UTC today GitHub opened that critical incident, later narrowing it to "degraded availability for the Kimi K3 model in Copilot products and IDE surfaces... due to an issue with an upstream model provider." Again no name. Kimi K3 is Moonshot AI's model — and Moonshot's own status page, status.moonshot.cn, showed All Systems Operational when we checked, an hour and forty minutes into GitHub's incident. Anthropic, OpenAI, and Cursor were green as well.

So the middleman can lag the upstream by hours, and the middleman can alarm while every upstream page you can find stays silent — either because the fault sits in a hosting layer the notice does not name, or because that upstream simply has not opened an incident. Both readings end at the same practice: the tool's page and the provider's page are different instruments measuring different surfaces. You need both, and you need to know which one you are reading before you act on it.

The volume makes this worth automating rather than checking by hand. Anthropic's own page shows 22 incidents in August so far — roughly 33 hours of cumulative page-open time, six of them major and one critical, counted straight from incidents.json. At that rate, the difference between watching the right page and the wrong one is not a one-off. It is your mean time to detection, every few days.