AI outages, counted

Every AI app has a dependency it can't see: a model provider that, a few times a month, starts answering with errors. When Claude or ChatGPT goes down, the story usually lasts an afternoon on social media and then disappears. Nobody keeps a running count, so it's hard to say whether things are getting better or worse, which provider fails more, or how long a typical outage lasts.

So we counted. We downloaded the full incident history of 18 public status pages, from Anthropic, OpenAI, Google, Groq, Cohere, Mistral, xAI and other model providers to the tools built on them (GitHub Copilot, Cursor, Vercel, Supabase, Lovable), and normalised every incident since January 2023 into one table. Then we read the postmortems of the biggest outages, the SLAs the providers sell, and the issue tracker where developers report errors. One warning up front: status pages are written by the companies themselves. Every count below measures what a company chose to publish, which is not the same as how often it failed. The methodology explains how we counted and where the counts fall short.

Who posts the most incidents#

Anthropic and OpenAI started 2024 at about the same rate, around 15 incidents a month each. Both roughly doubled in 2025. In 2026 Anthropic kept climbing while OpenAI levelled off.

A count of posts is a count of a habit as much as of failures. Anthropic tends to post one incident per affected model ("Elevated errors on Claude Opus 4.6"): 217 of its 382 incidents in 2026 name a model. OpenAI more often groups several problems under one incident. The quarterly view shows how fast the habit can change: Anthropic posted around 45 incidents per 30 days in the first half of 2026, then 30 in the third quarter and 16.5 in October, while the number it labelled major or critical fell much less, from about 14 to about 10 per 30 days.

For anyone building on the API, one more difference matters. 69% of Anthropic's incidents touch its API, against 36% of OpenAI's, and 28% in 2026: most OpenAI incidents are about ChatGPT, Sora or Codex, not the API apps call. In 2026, 267 of Anthropic's 382 incidents listed the API, against 85 of OpenAI's 302.

What the pages call major#

Each page also labels its incidents: minor, major or critical. The label is the provider's own call (on incident.io pages it follows the worst component colour), so it isn't comparable across companies to the decimal. It is the best filter there is, though, because it is much less sensitive to how many small notices a company posts.

Anthropic's serious incidents went up while OpenAI's went down, and GitHub's nearly tripled. Counted in days, Anthropic had a major or critical incident open on 110 of the 304 days of 2026 so far. Its page actually shows 125, but 15 of those days come from one long incident titled "We've suspended access to Claude Mythos 5 and Claude Fable 5", open from 13 June to 1 July and labelled critical. That was a deliberate suspension of two models, not an outage, so we show both numbers.

GitHub's labels changed the most. It marked 36 incidents critical in the first ten months of 2026, after one in all of 2023, 2024 and 2025 together. GitHub Copilot alone had 67 incidents in that time, against 34 in all of 2025. We can't tell from the pages whether that's more failures or a new way of labelling them.

How fast they fix it#

Here the picture flips. Anthropic posts more incidents than OpenAI and labels more of them serious, but it closes them faster: a median of 62 minutes from the start of an incident to the "resolved" post, against 91 for OpenAI. The slow tail is where the difference is largest. One in ten Anthropic incidents stays open longer than 4.9 hours; for OpenAI that's 11.7 hours.

Durations on a status page are posting windows: from the first post, or the start time the provider gives, to the resolved post. They include the monitoring tail and can run longer than the outage. OpenAI's 11 December 2024 incident is open for 426 minutes on its page; the impact window in its postmortem is 262. Still, the shape is consistent with an outside study. Researchers at VU Amsterdam found that, in public data through August 2024, the median time to recover was 0.77 hours for the Anthropic API and 1.23 hours for the OpenAI API, and that ChatGPT's failures "take longer to resolve but occur less frequently" than Claude's.

So more posts isn't automatically worse. A company that posts every blip, and closes most of them within an hour, can look worse in a count than one that posts less and takes longer. The two measures that matter most for an app, how often the API itself is affected and how long it takes to recover, point in different directions for the two biggest providers.

When it breaks#

Incidents follow the working week. On the seven model-provider pages that give exact times, only 9.9% of incidents started on a Saturday or Sunday. Tuesday and Wednesday are the worst days.

The hour of day tells the same story. 40% of incidents start between 14:00 and 19:59 UTC, which is 7 am to 1 pm on the US West Coast in summer, and the single worst hour is 18:00 UTC. That fits what the postmortems below describe: most big outages start with a change someone made, and changes are made during working hours.

The biggest outages weren't the models#

We read the postmortems of eight big outages behind AI services since late 2024. None of them was a model failing. Every one began with a change to configuration or infrastructure: a feature file that doubled in size, a quota policy with blank fields, an operating-system update, a DNS automation race.

Anthropic's quality drop in August and September 2025 is on the list although nothing went down, because its cause was the same kind. Its postmortem traced the problems users reported to "infrastructure bugs alone": a routing bug, an output corruption and a compiler error on TPUs. About 30% of Claude Code users who made requests in that period had at least one message routed to the wrong server type.

Several postmortems name the same missing guards. Google's change "did not have appropriate error handling nor was it feature flag protected", and its recovery was slowed because Service Control lacked "randomized exponential backoff". OpenAI's June recovery was slowed by "the absence of break-glass tooling". Cloudflare called 18 November "Cloudflare's worst outage since 2019" and said it was not an attack.

The cloud outages are also the days when AI fails all at once. On an ordinary day between June and December 2025, three of our 18 pages had a new incident. On the day of the Cloudflare outage, twelve did.

On 12 June 2025, Anthropic, OpenAI, the Gemini API, Groq, Cohere and Vertex AI all had an incident open, along with Cursor, GitHub Copilot and Lovable. A second model provider is a good fallback, but on days like these it may be on the same cloud.

What an SLA covers#

The usual answer to outages is an SLA, a contract that promises uptime. The arithmetic is unforgiving. A 99.9% monthly SLA allows 43 minutes of downtime in a 30-day month, and a 99.5% one allows 3.6 hours. Most of the outages above were longer than a whole month's 99.9% allowance on their own.

And most AI APIs don't come with one. Anthropic's documentation says standard API requests run with "best-effort availability". Its Priority Tier "targets 99.5 percent uptime", but the same page now calls service tiers legacy and says Priority Tier commitments are no longer sold. OpenAI's 99.9% SLA comes with Scale Tier and Fast mode, and only for Enterprise customers. The Scale Tier page says it's available on models released before GPT-5.6, with newer models on a separate Reserved Tier.

The pattern is that the SLAs live with the clouds. If an uptime promise matters to you, you buy the same model through Bedrock, Vertex or Azure, and even then the credit is a share of your bill. For scale, the AWS outage alone cost US companies an estimated $500 million to $650 million, according to the insurer Parametrix, across everything that runs on AWS, not only AI.

What developers see: 529s#

When Anthropic's API is overloaded it returns a 529, which its documentation describes as an error that "can occur when the API experiences high traffic across all users". It's separate from the 429 a single account gets for going over its rate limit. For people using Claude Code, a 529 is what an outage looks like, so we counted the GitHub issues in anthropics/claude-code with "overloaded" or "529" in the title.

The July 2025 peak came just before Anthropic announced weekly usage limits for Claude Code. "Claude Code has experienced unprecedented demand since launch," an Anthropic spokesperson told TechCrunch at the time. The March 2026 spike followed a 2 March outage in which claude.ai and Claude Code sign-ins failed while the API kept working; Bloomberg's headline said Claude went down amid "unprecedented demand".

Developers and the status page mostly agree. On all nine days with the most such issues, Anthropic's status page had an incident open, and on six of them a major or critical one. On 18 March 2026, the busiest day with 18 issues, the page had four incidents open, all major, three of them about Opus 4.6. The issue titles say what an outage costs in an agent workflow: one, #89267, reads "Subagent killed by 529 Overloaded loses all work — no partial result, full relaunch required".

Routing around it#

The common fix is a second route to the same model. OpenRouter, which sends requests to many hosts of the same models, publishes a one-day success rate for every host it routes to. We took one snapshot, for the 24 hours to 19:00 UTC on 31 October 2026, across 1,335 endpoints. It's one day, every endpoint counts once whatever its traffic, and 429 rate-limit errors don't count as failures, so it's not a ranking. It does show what redundancy buys.

On that day every Claude endpoint served directly by Anthropic, by Claude Platform on AWS and by Bedrock answered 100% of requests; on another day the numbers will be different. The lesson isn't which host is best. It's that any one of them has bad days, and the chance that all of them do at once is much smaller.

What this means if you build with AI#

1. Retry, with backoff and jitter. Treat 529, 503 and other 5xx errors as temporary: retry a few times with exponential backoff, add random jitter, and honour the retry-after header. Anthropic's SDK already retries twice by default. The jitter matters: Google's own recovery on 12 June 2025 was slowed by retries without it. Don't retry a 400, and cap the total time.
2. Have a second provider for the same model. Claude is sold by Anthropic, Bedrock and Vertex; GPT models by OpenAI and Azure. That's also where the SLAs are. Keep the keys set up and the code path tested, because a fallback you've never run doesn't work on the day you need it.
3. Have a fallback model for when a whole provider is down. Big outages last hours: a quarter of OpenAI's incidents stayed open four hours or more. Pick a model from another company, test your prompts on it, and keep the conversation history on your side so you can hand it over.
4. Watch the status pages, and don't wait for them. Most of the pages we read publish an RSS or Atom feed or a JSON list of incidents, so you can pipe them into Slack. Subscribe to the clouds too: a Cloudflare or Google Cloud incident reaches every AI provider at once. But alert on your own error rate as well, because many incidents are posted after they started.
5. Design the degraded state. Decide what your app does when the model is unavailable: queue the request, show a cached answer, or say plainly that the AI part is down and the rest still works. It's much easier to build that before the first outage than during it.
6. Don't let your coding agent be your deploy path. If shipping a fix needs Claude Code or Cursor to be up, an outage on their side stops your release. Keep deploys in a script or a CI step you can run by hand, and have long agent runs save their work as they go: a subagent killed by a 529 can lose everything.
7. Expect trouble on weekday afternoons, UTC. Most incidents start between 14:00 and 20:00 UTC on a weekday. If your traffic peaks then too, that's when to have someone watching.

We build host0 for the step after the build: an app your agent made goes live at a link you can share. Publishing is a plain script and a REST call, so it doesn't need the agent that wrote the app to be up.

Methodology#

We used public data only, collected on 31 October 2026.

• Status pages. The full incident history of 13 status pages: Anthropic, GitHub and Vercel through each Atlassian Statuspage's history and per-incident JSON; OpenAI, Groq, Fireworks, Cohere, Perplexity, Supabase, Lovable and v0 through each incident.io page's own JSON, one month at a time; Google Cloud (for Vertex AI incidents) by combining 49 monthly Wayback captures of its rolling 365-day incident file with the live one. The Gemini API's AI Studio page was read once in a browser. Five more pages are partial: xAI, Cursor and DeepSeek rebuilt from Wayback captures of their feeds, Mistral and Replit from their last 50 incidents only. Together AI and OpenRouter publish no incident history we could reach.
• Normalisation. One row per incident, 1 January 2023 to 31 October 2026, all times in UTC. Scheduled maintenance is dropped. The start is the earliest time the page gives, including backdated starts; resolved is the first "resolved" post after the last unresolved one, so later postmortem posts don't stretch durations. Impact is the page's own label; on incident.io pages it's the worst component status, the same mapping their own feeds use. We removed 63 duplicates (same title within 5 minutes), 60 of them on xAI's feed.
• Checks. We re-read 20 random incidents on their own pages (titles 20 of 20, Atlassian labels and times 11 of 11, incident.io start times 9 of 9), compared 200 incident.io incidents with each page's own feed (impact agreed on 199), and checked that each Atlassian page's latest 50 incidents were all in our set.
• Limits. Status pages are self-reported: counts measure what a company publishes, and companies post at different granularity. Labels are each company's call. Durations are posting windows and include monitoring tails. 2026 runs to October, so we compare monthly rates, never totals. Pages without labels (Gemini API, xAI, DeepSeek), with partial history, or with automated per-model incidents (Fireworks) are left out of comparisons.
• Postmortems and SLAs. The postmortems, SLA pages and API docs we cite were read on 31 October 2026; Anthropic's service tiers page had changed since our first read, and OpenAI's Scale Tier and Fast mode pages block scripts, so they were read through Wayback copies from 15 October and 17 August.
• Claude Code issues. GitHub's issue search for anthropics/claude-code, issues with "overloaded" or "529" in the title (257), by month opened. 28 of 30 random matches were about overload errors. Many reports have other titles, so it's a floor.
• OpenRouter. One pull of every model's endpoints from the public API at 19:00 UTC on 31 October 2026, using each endpoint's uptime_last_1d (successful requests over all requests, not counting user errors or 429s). 145 endpoints without enough traffic were left out.

The data pack, with every source, tier, the spot-check log and a do-not-cite list, is in our repository at docs/research/2026-10-31-ai-outages.md. The full incident table (incidents.csv), the series behind every chart and the scripts that compute them are in docs/research/2026-10-31-ai-outages-data/.

Open questions#

• Why did Anthropic's count halve after July 2026? Its major and critical incidents didn't fall with it. A change in how it posts is the likeliest reading, but the page doesn't say.
• Is GitHub failing more, or labelling differently? 36 critical incidents in ten months, after one in three years, looks like a policy change as much as a reliability one.
• How much downtime do status pages miss? Every number here is what a company chose to post. An independent monitor of real API calls, over months and weighted by traffic, would answer it; we didn't find a public one.
• What does a coding-agent outage cost? Nobody has measured the developer hours lost when Claude Code, Codex or Cursor stall. We found no credible estimate.