Claude AI Incident History and Outage Log

Claude is reliable most of the time — but like every large AI service, it has a documented history of incidents, and that history is worth knowing. Studying past Claude AI outages tells you what tends to break, how long recovery usually takes, and how Anthropic communicates when things go wrong — which is exactly the information you need to design around downtime instead of being surprised by it. This article logs the notable incidents I can verify from Anthropic’s own postmortems and status history, then pulls out the patterns and the resilience lessons.

TL;DR: The most significant documented episode was August–September 2025, when three overlapping infrastructure bugs degraded Claude’s response quality and prompted an unusually detailed public postmortem. Most other incidents are short and partial — elevated errors on specific models or components, typically resolved in minutes to hours. Common causes across incidents: capacity pressure, infrastructure and deployment changes, and serving-stack bugs. Anthropic communicates through status.anthropic.com using an Investigating → Identified → Monitoring → Resolved lifecycle. If you build on the API, retries with backoff and a model fallback absorb the large majority of real-world incidents.

Notable Documented Claude AI Outages and Incidents

This isn’t an exhaustive log — Anthropic’s status page records many small, fast-resolved incidents that never make news — but these are verifiable episodes that illustrate the range, from quality degradation you could barely detect to error spikes across the whole product line.

When	What happened	Scope and resolution
Aug–early Sep 2025	Three overlapping infrastructure bugs intermittently degraded Claude’s response quality (not availability), including a context-window routing error and a miscompiled token-selection optimization on TPU hardware	Rolled back and fixed across several weeks; Anthropic published a detailed public postmortem
Mar 26–27, 2026	Degradation tied to networking problems in Anthropic’s own serving infrastructure	Fixed by migrating workloads to healthy infrastructure, per Anthropic’s postmortem notes
Jun 12 – Jul 1, 2026	Anthropic suspended access to Claude Fable 5 and Claude Mythos 5 for regulatory and export-control reasons, announced in a critical status-page notice on June 13 — a policy suspension, not an infrastructure outage	Models offline for roughly 19 days; access restored July 1 with a hardened safety classifier
Jun 23, 2026	Elevated error rates across multiple models, affecting claude.ai, the Console, the API, Claude Code, and Cowork	Investigating at 14:19 UTC, Identified by 14:25 UTC — cause isolated within about six minutes
Jul 8–10, 2026	A cluster of smaller incidents on the status page: elevated errors for Claude Opus 4.8 (Jul 10), degraded performance for Claude Code on the web and MCP authorization issues (Jul 8)	Component-scoped, resolved same day

The August–September 2025 episode deserves special attention because it’s the best-documented AI serving incident anywhere. Users reported degraded answers for weeks before the causes were isolated — the reports were initially hard to distinguish from normal feedback noise. The eventual investigation found three separate bugs, including one where a fix for an earlier workaround exposed a deeper flaw in an approximate top-k token-selection optimization. Anthropic’s public postmortem is worth reading in full: it’s a rare look inside a production LLM serving stack, and it explains why “is Claude down?” is sometimes the wrong question — the service can be fully up and still subtly wrong.

The biggest 2026 event was different in kind: the June 12 – July 1 suspension of Claude Fable 5 and Claude Mythos 5. This was a regulatory and export-control suspension, not an infrastructure outage — nothing broke. Anthropic announced it in a critical notice posted to the status page on June 13, stating that access to both models had been suspended, and the models stayed offline for roughly 19 days before access was restored on July 1 alongside a hardened safety classifier. The lesson for anyone building on Claude is that a specific model can become unavailable for weeks while every infrastructure component stays green — which is its own argument for model fallbacks. The full timeline is in our Claude Fable 5 suspension deep dive.

What Typically Causes Claude AI Outages

Across the incidents above and the steady drumbeat of smaller status-page entries, the causes cluster into four buckets:

• Capacity and demand spikes. LLM inference is expensive, and GPU/TPU capacity can’t be scaled up in seconds. Product launches, viral moments, and weekday peak hours all push demand against fixed short-term supply — surfacing as capacity messages on claude.ai and 529 “overloaded” errors on the API.
• Deployments and configuration changes. Like any fast-moving service, many incidents trace back to a change: a rollout that misbehaves, a config push with unintended effects. These usually resolve quickly because the fix is a rollback.
• Infrastructure and serving-stack bugs. The 2025 postmortem is the canonical example — hardware-specific compiler behavior and routing logic interacting in ways that took weeks to isolate. These are the rarest and hardest incidents.
• Upstream dependencies. Claude runs on major cloud providers, and no cloud is immune to networking or regional problems. The March 2026 episode — resolved by migrating workloads to healthy infrastructure — shows how the fix for this class is often rerouting rather than repairing.

Note what’s mostly absent from that list: total multi-hour platform blackouts. The realistic threat model for a Claude user is partial degradation — one model erroring, one surface slow — which is why the diagnosis skills in our “is Claude AI down” playbook matter more than outage panic.

How Anthropic Communicates During Incidents

Anthropic’s incident communication runs through its official status page, where every incident moves through four timestamped stages: Investigating (problem confirmed), Identified (cause known, fix underway), Monitoring (fix deployed, watching recovery), and Resolved. Component states distinguish degraded performance from partial and major outages, and the full update trail stays public in the incident history afterward. You can subscribe to these updates by email, SMS, Slack, webhook, or RSS — our guide to reading the Claude AI status page walks through every channel and what each severity level means.

For the biggest issues, Anthropic goes further and publishes engineering postmortems. The 2025 quality-degradation writeup explicitly noted that the company doesn’t usually share that level of infrastructure detail but judged the scope of the problem to warrant it. That’s the pattern to expect: routine incidents get status-page updates measured in minutes; systemic ones eventually get a public technical explanation.

Patterns Worth Noticing in Claude’s Incident History

• Partial beats total. Most entries name a specific model or component, not the whole platform. A fallback path — different model, different surface — keeps you working through the majority of incidents.
• Acknowledgment is fast; small incidents are frequent. The June 2026 incident went from Investigating to Identified in about six minutes, and a typical fortnight on the status page contains several small same-day-resolved entries. Frequency of small incidents is normal for a service shipping this quickly; what matters is time-to-resolution.
• Quality incidents are sneakier than availability incidents. The 2025 episode produced no dramatic error pages — just worse answers. If Claude seems off but nothing is posted, you may be early to something real; it has happened before.

Resilience Lessons for API Users

If you run Claude in production, the incident history translates directly into engineering practice:

1. Retry with exponential backoff and jitter. Treat 500 and 529 as retryable. The official SDKs retry transient errors automatically — keep that enabled and tune max retries to your latency budget.
2. Distinguish 429 from 529 in your metrics. A 429 is your quota; a 529 is their capacity. Alerting on them separately tells you instantly whether to fix your traffic or check the status page — our Claude API rate limits guide covers the 429 side in depth.
3. Build a model fallback. Incidents scoped to one model are common enough that falling back to a sibling model on repeated errors is the single highest-value resilience feature you can ship.
4. Defer what can wait. Batch and background workloads belong in queues (or the Message Batches API) so an hour of degradation costs you nothing but delay.
5. Subscribe to the webhook. Pipe status-page updates into your incident tooling so on-call engineers see “confirmed at Anthropic” next to their own alerts instead of debugging blind.
6. Watch quality, not just errors. The 2025 postmortem’s core lesson: availability monitoring alone would have missed it. If your product depends on output quality, sample and evaluate outputs continuously.

Common Mistakes When Reasoning About Claude Outages

• Judging reliability from headlines. News coverage overweights rare big incidents and ignores months of quiet operation; the status page’s uptime history is the honest denominator.
• Assuming every glitch is an outage. Usage caps, rate limits, and local network problems account for a large share of “Claude is down” complaints on any given day.
• Treating past uptime as a guarantee. Incident history informs design; it doesn’t promise the future. Build the fallback anyway.

Next Steps

The record so far shows a service that fails partially, recovers quickly, and — when something systemic happens — explains itself in public with unusual candor. Keep the incident history in your mental model, wire up the subscription channels, and build the retry-and-fallback basics, and Claude AI outages become a minor operational fact rather than an emergency. For the live-triage side of this topic, start at our status hub.

FAQ