If you build on more than one frontier model — and most production systems do — your incident playbook involves more than one status page. OpenAI, Google, and Anthropic each publish a public dashboard. They are not directly comparable, even though all three are nominally answering the same question.
This is a guided reading of the three pages, focused on what they actually communicate, where each is strongest, and how to combine them into a single triage view during a real incident. Where this dashboard surfaces things the official pages do not, we say so explicitly.
The three pages, briefly
| Provider | Public page | Underlying tech |
|---|---|---|
| Anthropic | status.claude.com | Atlassian Statuspage |
| OpenAI | status.openai.com | Atlassian Statuspage |
| Google (Gemini) | status.cloud.google.com/products/vertex-ai-generative-ai | Google’s own Service Health platform |
The first split matters. Two of the three (Anthropic and OpenAI) use the same Atlassian Statuspage product, which means the public JSON APIs are structurally identical and you can read both with the same parser. Google publishes through its own Service Health system, which has a different shape and a different cadence.
What each page tells you
Anthropic — component-driven, incident-driven, terse
Anthropic’s page surfaces five components: claude.ai, platform.claude.com, the API, Claude Code, and Claude for Government. Each has a current status (operational / degraded / partial outage / major outage). Below the components is an incident history with per-incident updates posted by on-call engineers.
What Anthropic communicates well:
- Per-component scope. When a single surface is affected, the component grid tells you which one.
- Real-time updates during long incidents. Multiple updates per hour during major events, with each update timestamped.
- A clean public API. Both
summary.jsonandincidents.jsonare unauthenticated, CORS-permissive, and explicitly intended for third-party use.
What it under-communicates:
- Per-model scope. A model-tier-specific incident shows up on the Claude API component generically; you have to read the incident text to learn which model is affected.
- Regional scope. Same — the page describes affected regions in the incident text, not in a structured field.
- Latency from your region. Not on the page at all. This is one of the gaps this dashboard tries to fill.
OpenAI — same product, more components, busier
OpenAI’s status page uses the same Atlassian Statuspage product. The difference is that OpenAI publishes far more components — last we checked there were a dozen-plus, broken down by model family and surface (ChatGPT, the API, individual model variants, Sora, Realtime API, etc.). The granularity is higher, which is genuinely useful when an incident is scoped to one model family but not another.
What OpenAI communicates well:
- Per-model decomposition. “GPT-5 elevated error rates” appears as its own component status, separate from the rest of the API. This is what most users want and Anthropic does not provide.
- Density of incident updates. OpenAI is comfortable posting multiple short updates per incident, often with structured “current status” reads.
What it under-communicates:
- The forest from the trees. With twelve-plus components, a single user staring at the page during an outage may not immediately know which component matters for their use case. Anthropic’s five-component grid is easier to read at a glance.
- Outage history searchability. Volume of past incidents is high; finding the one you remember requires some scrolling.
OpenAI’s API: https://status.openai.com/api/v2/summary.json (same shape as Anthropic’s).
Gemini / Vertex AI — Google’s separate world
Google’s generative AI status flows through the Google Cloud Service Health page, not a Statuspage instance. The Vertex AI section covers Gemini models alongside the rest of the platform. The page format is different: Google publishes incidents tagged with affected products and regions, and shows them on a unified Cloud Service Health timeline rather than a per-component grid.
What Google communicates well:
- Region-scoped detail. Google’s incidents almost always specify the affected GCP region, which is more precise than the typical Anthropic or OpenAI incident text.
- Cross-product context. A single Cloud event might affect Vertex AI plus four other products, and Google shows them together so you can see the shared root cause.
- Mature postmortem culture. Google publishes more formal post-incident reports more reliably than the Statuspage providers.
What it under-communicates:
- Real-time during fast-moving events. Updates are less frequent than what you get on the Statuspage providers during an active incident.
- A simple “is Gemini up right now” answer. The unified Cloud page is comprehensive but it is not built for a user asking the binary question. You have to filter.
- An equivalent public JSON API. Google’s data is harder to consume programmatically — there is a JSON feed but the structure and reliability differ from the Atlassian product.
During a real incident, what to read in what order
Speaking from experience watching all three pages during cross-vendor outages:
Step 1 — the per-component grid on the relevant page. It tells you whether the provider has officially acknowledged something. This takes ten seconds. If green, the next step is verifying you are not looking at a local issue.
Step 2 — the latency widget on a third-party dashboard like this one. If the official page is green but your application is failing, an independent latency probe answers “is the front door reachable from my region.” If the answer is no, your problem is upstream of you and the official page just has not caught up.
Step 3 — community report counts. During incidents, community reports lead the Statuspage indicator by 5–30 minutes. Spike in reports + green official page = the incident is real but unacknowledged. Spike in reports + red official page = you are in the middle of a known event.
Step 4 — the actual incident text. Read it. The official text on Anthropic and OpenAI pages tells you the affected scope, which is the thing you actually need to make a fall-back decision. The “is the indicator red” question is binary; the “what subset is broken” question is what determines whether your code path is affected.
For Google’s Service Health, replace step 4 with “filter to Vertex AI / your specific region” and the rest of the flow is the same.
What this dashboard adds
Three things, deliberately:
- A latency widget that is independent of Anthropic’s own telemetry. When the official page is wrong, the latency widget will not be wrong in the same way. Disagreement between the two is itself information.
- A community report sidebar. Volunteer-submitted, anonymous, rate-limited, three-day rolling. It catches the early signal — the period before incidents are officially classified.
- A single page that combines them. The official Anthropic page tells you Anthropic’s view. This page tells you Anthropic’s view, plus latency from 17 countries, plus what users are reporting, all on one render. During a real outage, that combination is what you want open in a tab.
We do not try to replace any of the three official pages. The official pages are the source of truth for incident classification, postmortems, and the official record. We sit alongside.
The case for reading all three even if you only use one model
If your production system uses Claude exclusively, do you need to watch OpenAI’s status page?
Sometimes. Cross-vendor incidents that look like AI-industry-wide problems often turn out to share an upstream cause (a shared cloud region, a shared CDN provider, a shared DNS issue). When OpenAI and Anthropic both show degradation simultaneously, the pattern usually points to a shared infrastructure player — typically AWS or Cloudflare. Knowing the shape of that shared dependency helps you decide whether the right fallback is “switch to Gemini” or “wait it out because everyone is broken.”
This is not a hypothetical. The most memorable cross-vendor moments in the last year have been exactly this pattern — AWS regional events, Cloudflare control-plane issues, DNS provider hiccups — manifesting as simultaneous yellow indicators on multiple frontier-model status pages. Watching only one page would have made the pattern invisible.
A short comparison table
| Question | Anthropic | OpenAI | Gemini |
|---|---|---|---|
| Per-component grid | yes (5) | yes (12+) | partial |
| Per-model component | no | yes | partial |
| Region tags on incidents | text only | text only | structured |
| Public JSON API | yes | yes | partial |
| Latency from your region | no | no | no |
| Community reports | no | no | no |
| Incident updates during long events | frequent | very frequent | less frequent |
| Postmortem follow-through | sometimes | sometimes | typically published |
We do not maintain rival dashboards for OpenAI and Gemini. If you need that breadth, sites like Downdetector aggregate all three (along with hundreds of other services) at the price of less domain-specific signal. Our scope is Claude.
Bottom line
The three official pages each communicate different things, and none of them communicates everything. The reading order during an incident is roughly: official page → independent latency check → community signal → official incident text. The closer your build target is to a single provider, the more value you get from a dashboard like this one — which is purpose-built for that provider, with the methodology written down on the page. The more cross-vendor your build is, the more value you get from reading all three official pages in parallel, watching for the pattern where they degrade together.
In both cases, the discipline is the same: do not read one source, do not stare at a single number, and do not assume the absence of an alert means the absence of a problem.