AI Provider Status History
Incident timelines and uptime comparison for Anthropic, OpenAI and Google AI APIs.
Recent incidents — Anthropicsnapshot 2026-06-01
Live status page ↗- 2026-05-19 · Elevated 529 overloaded errors on Claude Sonnet during peak hourspartial · 95 min
- 2026-04-28 · API errors across all models — elevated 5xx ratesmajor · 42 min
- 2026-04-07 · Degraded latency on the Messages API; streaming unaffectedpartial · 130 min
- 2026-03-14 · Console and API authentication failuresmajor · 25 min
Network request fires only when you click — nothing is fetched on page load.
90-day uptime comparison (from snapshot)
| Provider | Uptime | Incidents | Downtime |
|---|---|---|---|
| Anthropic | 99.71% | 4 | 292 min |
| OpenAI | 99.64% | 4 | 415 min |
| Google AI (Gemini)highest | 99.78% | 3 | 180 min |
Methodology: declared incident minutes ÷ window minutes, from each provider's public status history as of 2026-06-01. Undeclared degradation doesn't count — treat as directional, not an SLA audit. Always confirm against the live status pages.
How it works
This page gives you the reliability picture for the three major AI API providers — Anthropic, OpenAI and Google — in one place: a recent incident timeline per provider, an uptime comparison table, and direct links to the live status pages where outages are declared first. Use the tabs to switch providers and the check button if you want your browser to attempt a live reachability probe right now.
Honesty about methodology is the design principle here. The incident history is a snapshot dataset — curated from public status pages and postmortems, labeled with its snapshot date — rather than a live feed, because browser security rules prevent reliable cross-origin reads of most status APIs, and a widget that silently shows stale data as live would be actively harmful. Uptime percentages are computed from declared incident minutes over the window, which inherits the providers' own reporting standards: undeclared degradation does not count. Read the table as directional comparison, not SLA evidence.
What should you do with this information? First, calibrate expectations: every provider in the table has real incidents every quarter, so agent pipelines need backoff and retry logic as table stakes — see our HTTP status reference for per-code retry guidance, especially 429, 529 and the Cloudflare 52x family. Second, if AI calls sit on your critical path at scale, uncorrelated failures across providers make two-provider failover genuinely effective insurance. Third, subscribe to the native status-page notifications linked here; they are authoritative, if sometimes minutes behind reality.
That lag is the gap worth closing: providers declare incidents after their own monitoring confirms them, while your requests started failing earlier. The teams that notice outages first are the ones watching their own error rates per provider in real time — which is what FORG's session tracking does for agentic coding traffic, turning "is Claude down?" from a search query into a dashboard glance — and pairing each spike with the session and model that produced it, so diagnosis takes seconds instead of a hunt through logs.
Frequently asked questions
Where does the incident data on this page come from?
The incident history is a curated snapshot dataset assembled from the providers' public status pages and postmortems, with the snapshot date labeled clearly above the timeline. It is deliberately not a live feed: browsers cannot reliably fetch most status-page APIs cross-origin, and a stale-but-honest snapshot beats a live widget that silently fails. The live links next to each provider go straight to the authoritative source.
How is the uptime percentage calculated?
From the incident snapshot: total minutes of declared major and partial outages over the window, divided by total minutes in the window, subtracted from 100%. This matches how providers self-report, which means it inherits their biases — degraded performance that was never declared an incident does not count against uptime. Treat the comparison as directionally useful, not as an SLA audit.
Should I build multi-provider failover for my agents?
At meaningful scale, yes — every major provider has multiple incidents per quarter, and they are uncorrelated, so two-provider redundancy turns a hard outage into a quality degradation. The practical pattern: an abstraction layer or gateway that retries against a second provider after N consecutive 5xx/529 responses, with prompt templates tested against both model families in advance. For most small teams, honest backoff plus status-page awareness is enough.
How do I get alerted when a provider goes down?
Every provider status page offers native subscriptions — email, webhook, RSS and sometimes Slack — linked directly from this page; subscribe to those for authoritative notifications. The gap they leave is your side of the equation: provider status pages tell you when THEY declare a problem, often minutes after your requests started failing. Alerting on your own error rates catches incidents earlier, which is what FORG's session tracking is for.
Why does the current-status check sometimes fall back to links?
The check button attempts a browser fetch of each provider's status endpoint, and browsers enforce CORS — most status APIs do not permit cross-origin reads from arbitrary websites. When the fetch is blocked we say so plainly and surface the direct status-page links instead of pretending to know. A tool that displays a green dot it cannot verify would be worse than no tool.
FORG tracks this automatically across every agent session — live cost attribution, budgets, and alerts.
Start tracking with FORG