Summary
- A major Haiku 4.5 incident ran from 13:04:35 to 16:38:26 UTC on 21 July and returned to an identified state after an initial monitoring update.
- A separate critical multi-model record said users experienced elevated errors from 15:28 to 16:26 UTC; its incident page remained open until 18:18.
- Another critical record disrupted document creation and Claude workflow tools from 17:40 to 18:03.
- A minor Opus 4.1 incident affected the API and Claude Code from 08:34 to 09:00 on 22 July.
- Anthropic published no common root cause, affected-user count, request share, regional breakdown or service-credit conclusion.
At 13:22 UTC, Anthropic said it had implemented a fix for elevated errors on Haiku 4.5 and was monitoring the result. Eighty-two minutes later, the incident returned to “identified”. That reversal is the most useful fact in a crowded status history: recovery had not held.
The rest of the operating day cannot responsibly be collapsed into a single outage. Anthropic opened other records with different severities, components and clocks. Together they show a service estate under repeated pressure. Separately, they preserve the boundary between evidence and diagnosis.
Haiku failed the first recovery test
The Haiku 4.5 record began at 13:04:35 UTC and carried a major impact label. Its listed components covered claude.ai, the Console, API, Claude Code and Cowork. Anthropic moved to identified at 13:14, monitoring at 13:22, back to identified at 14:44, monitoring again at 15:30 and resolved at 16:38.
The return from monitoring does not disclose why the first remedy was limited public evidence. It does prove that a greenward status change was not durable. Customers should therefore distinguish provider status from their own synthetic success rate and backlog health.
The multi-model record has two durations
A critical incident for several models opened at 15:35. Its final update later specified that users experienced elevated errors from 15:28 to 16:26. The page itself did not close until 18:18 after identification, monitoring and resolution work.
Those are different measurements. The first is the provider's eventual statement of the user-impact window. The second is the lifecycle of the incident record. Reporting the entire page-open period as continuous customer errors would overstate what Anthropic said; reporting only 58 minutes would omit the operational uncertainty before closure.
The record named claude.ai, the API, Claude Code and Cowork. It overlapped Haiku, but timing and shared components do not establish that both entries had the same fault.
Workflow features then became their own incident
At 17:40, Anthropic opened another critical record for a disruption affecting document creation in claude.ai, Cowork Remote, Claude Code, Claude Code on the Web, Claude Tag and Claude Design. It moved through repeated identified updates, monitoring at 17:51 and resolution at 18:03.
This record is short but operationally distinct. A model may answer while an orchestration surface, remote environment or document workflow fails. Teams that rely on Claude as part of a production process need separate probes for inference, tool execution and the workspace that surrounds them.
On 22 July, Opus 4.1 added a fourth clock. Anthropic identified elevated errors at 08:34, moved to monitoring at 08:45 and resolved the minor API and Claude Code incident at 09:00.
Status taxonomy can fragment one business day
For a customer, the four pages may feel like one unreliable day. For engineering analysis, they remain separate until Anthropic supplies a common mechanism. Severity labels also cannot be summed: a major model incident, two critical records and one minor incident do not form a mathematical “total severity”.
Anthropic disclosed no user population, error percentages, geography, data loss or SLA treatment. The reliable business mechanism is narrower. Repeated model and workflow degradation forces teams to pause queues, validate recovery independently and decide whether work can move to another model or provider.
A useful postmortem would map these records onto shared dependencies and explain why Haiku returned after the first monitoring state. Until then, the disciplined conclusion is procedural: customers saw overlapping and successive failures across model and workflow surfaces, but the public evidence supports four clocks, not one invented root cause.