Claude logged roughly 20 incidents in 24 days, per Anthropic's own status page

Nearly an incident a day

Open Claude on a weekday in August 2026 and there was a fair chance of meeting a spinner, an error, or a "server is busy" message instead of an answer. According to a dev.to analysis published on 4 September, that pattern is documented by Anthropic itself: the company's public status page logged roughly twenty separate incidents in the first twenty-four days of the month — a mix of elevated error rates, degraded performance and a few outright service disruptions. That is close to one incident per day.

The dev.to post reconstructs the month incident by incident from the status history. Elevated errors on Sonnet 5 on 3 August; elevated errors across many models on 4 August; degraded performance across multiple models for most of a working day on 5 August; more degradation on 12 August; elevated errors on Mythos 5, Fable 5 and Sonnet 5 on 13 August; two service disruptions in a single day on 14 August; a disruption logged at the most severe "critical" level on 16 August; three consecutive days of degraded performance repeatedly naming Opus 5 on 17 through 19 August; and another burst of elevated errors on 20 August.

As the post went live on 24 August, a fresh incident rated "major" was still unresolved. Anthropic titled it "Elevated errors for multiple models", began investigating at 05:06 UTC, and within the hour reported it had identified the cause of elevated errors on requests to Claude Mythos 5, Claude Fable 5, Claude Opus 5 and other Claude models. The affected components were the broadest possible set: claude.ai, the Claude API, Claude Code and Cowork — the front door, the developer platform, the coding tool and the agent workspace, all failing at once, leaving paying users no alternative surface to route around.

Failed requests can still consume quota

The detail that turns this from an engineering story into a customer one is metering. Claude's paid plans do not sell unlimited use; they limit consumption against a rolling five-hour window plus a weekly cap. When the service is overloaded, a request can still draw down that allowance and then fail.

Users on r/ClaudeAI described exactly that on 24 August, according to the post: one reported that 23% of a five-hour limit had been consumed by three prompts that returned "server is busy", with four more hours of waiting ahead; another said the service had been down for two hours. The dev.to author presents these as user reports rather than audited measurements, but notes the mechanism they describe is real by design — a fixed budget spent on failed requests is gone whether or not anything came back. On a free tier an outage costs time; on a metered subscription it costs time and quota.

A flagship launch, then a wobble

Timing adds context without proving anything. Anthropic launched Claude Opus 5, its new premium flagship, on 24 July 2026, and the reliability run began within weeks, repeatedly naming Opus 5 among the affected models. The dev.to piece reads this as plausible capacity strain — a heavier, more capable model lands, demand surges, and infrastructure strains — but it explicitly stops short of asserting a cause, since Anthropic has not published a root-cause analysis. The same tension, it argues, applies across the frontier race, where launch cadence is optimised and reliability is the quiet variable traded away.

Transparency cuts both ways

The source gives Anthropic real credit. The status page is public and granular, with incident-by-incident updates and timestamps, and the entire record above comes from data the company published about itself. Most incidents were also short — degraded performance or elevated errors lasting well under a couple of hours — rather than multi-day blackouts, and serving a state-of-the-art model to heavy agentic workloads that hammer the API is a genuinely hard operational problem that no lab has solved perfectly.

Even so, the piece argues, "short and frequent" is still a pattern, and for a professional tool reliability is not a bonus feature — alongside honest limits, it is the product.

Why it matters

For developers building on the Claude API, a month of near-daily incidents makes a critical dependency flaky, and the 24 August event shows a single failure can span every surface at once, with no workaround. For subscribers, the combination of metered limits and unreliable service means paying for attempts rather than answers — quota spent on requests that never returned anything. The status page documents the problem thoroughly; it does not refund the time or tokens lost to it.