Claude Has an Incident on Half of All Days. Here’s How to Build for It

We read every incident on Anthropic's status page, status.claude.com: 934 of them, from the first in March 2023 to 26 October 2026. In 2025 and 2026, Claude had at least one incident on 57% of days, and a major or critical one on about one day in four.

That isn't a case against Claude. Most incidents are minor and fixed within the hour, and every large AI provider runs a busy status page. It's a case for treating incidents as part of normal operations, and building your product so they don't become your customers' problem.

If your product depends on a model, its reliability is your job, not your vendor's. The data shows where to start.

The status page in numbers

Year	Incidents	Critical	Major	Resolved within 1 hour
2023 (from March)	30	4	1	81%
2024	191	5	79	55%
2025	335	22	99	48%
2026 (to 26 Oct)	378	18	108	54%

Incidents grew as Claude grew, from one chat app and an API to several model families, desktop and mobile apps, Claude Code and Cowork. In 2026, 60% of incidents were rated minor and 5% critical, and the median was resolved 55 minutes after the first update. The busiest month on record was February 2026 (58 incidents); September and October 2026 had 13 each.

Part 1: Build for incidents as normal

Incidents come in clusters

In 2025–26, 70% of major or critical incidents were followed by another incident within 24 hours, and 77 days had three or more. A bad day tends to stay bad.

Build for it: put a circuit breaker in front of the model that switches to a fallback when error rates rise, and keep it there for a few hours after a major incident instead of switching back at the first sign of recovery. Queue work that can wait and retry it with backoff.

The biggest outages take everything down together

The most severe incidents name the API, the Console and claude.ai in the same breath: “Claude.ai, Console, and API not available” (March 2025), “Elevated errors on Claude.ai, API, Claude Code” (April 2026), “claude.ai and API unavailable” (April 2026). Incidents whose titles name the API were critical 16% of the time, against 5% overall, and took a median 74 minutes to resolve, against 55.

Build for it: don't plan to fall back from the API to the chat app, or from one Claude product to another. A real fallback is a second model family or a second provider, tested in advance. Many incidents hit a single model, so even switching from one Claude model to another often keeps you running.

Not every failure is an outage

Titles about slowness rose from 6 in 2025 to 29 in 2026, and titles about billing, credits or usage limits from 6 to 15. 2026 also brought issues with structured outputs, TCP handshake failures on api.anthropic.com and the usage and analytics admin API. None of these show up as a clean “service down”.

Build for it: monitor response times, whether outputs are valid (does the JSON parse, does it match your schema) and cost per request, not just uptime. Retries during an incident can show up later as a spike on your bill.

When the incident is the quality of the answers

Some incidents never produce an error. Between August and early September 2025, three separate infrastructure bugs intermittently made Claude's answers worse: a context-window routing error, corrupted output, and a compiler bug on the TPU chips that run the models. Two status-page incidents link to Anthropic's explanation, A postmortem of three recent issues (17 September 2025). It's also one of the clearest public descriptions of how Claude actually produces text:

“When Claude generates text, it calculates probabilities for each possible next word, then randomly chooses a sample from this probability distribution. We use ‘top-p sampling’ to avoid nonsensical outputs—only considering words whose cumulative probability reaches a threshold (typically 0.99 or 0.999). On TPUs, our models run across multiple chips, with probability calculations happening in different locations. To sort these probabilities, we need to coordinate data between chips, which is complex.”
— Anthropic, A postmortem of three recent issues

In other words, every answer comes out of a sampling step spread across many chips. When something goes wrong in that machinery, Claude doesn't crash; it picks worse words. Your error rates stay flat and the status page can stay green while answers get worse.

Build for it: keep a small set of your own prompts with known good answers and run them against production every day. A drop in scores is your early warning, even when nothing reports an outage.

Incidents hit European working hours

Since 2025, incidents cluster on weekdays (Tuesday and Wednesday are the busiest, Sunday the quietest), and the first update most often lands between 13:00 and 15:00 UTC, when Europe's afternoon overlaps the US morning. The good news: night and weekend incidents were resolved no more slowly than daytime ones.

Build for it: plan support cover and customer messaging for the European afternoon, and subscribe to the status page by email, webhook or RSS so your team hears before your customers do.

Part 2: Don't upgrade on launch day

Each new model brings new capacity, new traffic and new edge cases. The data suggests the first weeks are the bumpiest. In the 30 days after a new model first appeared in an incident title:

Model	Incidents naming the family in the next 30 days	Typical 30 days
Opus 4.8 (May 2026)	30	about 13 for Opus in 2026
Opus 4.7 (April 2026)	18	about 13 for Opus in 2026
Sonnet 5 (July 2026)	13	about 9 for Sonnet in 2025–26
Fable 5.1, Mythos 5.1 (September 2026)	3 each	new families, no baseline

Two honest caveats. We dated each launch from its first appearance in an incident title, not its official release date, so the windows are approximate. And the most recent launches look much calmer, which suggests launches are getting smoother. The pattern is a reason to be careful, not a rule.

There's no public launch roadmap, but there are retirement dates

Anthropic doesn't publish dates for upcoming models; they're announced on the day, in its news and API release notes. What it does publish in advance are retirement dates for older models, on the model deprecations page in its documentation. Those are the upgrades you can't avoid, so they're the ones to plan around.

Build for it:

• Pin model versions in production. A launch should never change your traffic by itself.
• Detect launches automatically. A daily check of the API's model list, or a subscription to the release notes, tells you on day one.
• Treat the launch date as the start of your testing, not your switch. Run your own test set against the new model (see our QA framework), then move a small share of traffic, then the rest.
• Plan upgrades from retirement dates. Start testing the replacement as soon as your model's retirement is announced, not in its final month.

If you're regulated: AI outages are your incidents too

For banks, insurers and other financial firms in the EU, DORA treats an AI model provider as a technology supplier. Its outages belong in your incident process, its contract needs exit and continuity terms, and a supervisor can ask how you would cope if it failed. We cover the rules in Why AI Projects Stall in Europe.

• Log supplier incidents that affect your services, with impact and duration on your side, not just the status page's.
• Set thresholds in advance for when an AI incident is escalated or reported.
• Show a tested exit and fallback: the second model or provider from Part 1 is also your DORA exit plan.
• Ask for post-incident reports in the contract. Only 6 of the 934 public incident summaries mention a root cause or postmortem; enterprise customers can ask for more.

Your checklist

1. A circuit breaker and a tested fallback model or provider.
2. Stay on the fallback for a few hours after a major incident.
3. Monitoring for latency, output validity and cost, not just errors.
4. Support cover and status alerts for the European afternoon.
5. Pinned model versions, with an alert when a new model launches.
6. Your own tests and a gradual rollout before any model switch.
7. Upgrade plans driven by retirement dates.
8. If regulated: supplier incidents logged, thresholds set, exit plan tested.

How we measured

All 934 incidents are in one CSV file: date, title, Anthropic's impact rating, resolution message and a link to each incident. We collected them from the public history pages of status.claude.com on 26 October 2026. Some limits to keep in mind:

• “Days with an incident” includes minor ones that affected few users. Days with a major or critical incident are the better measure of real disruption (27%).
• The history doesn't list affected components, so API figures are based on incident titles and undercount API impact: most incidents are titled by model and affect the API too.
• Durations run from the first status update to resolution, not from when impact began, and incidents spanning midnight are left out of the medians.
• Launch windows start from the first incident naming a model, not the official release date.
• How incidents are reported and titled changes over time, so treat year-on-year comparisons as indicative.