Summary
- The first minor incident ran from 13:37:28 to 15:23:37 UTC and covered elevated errors on Opus 4.8 and Haiku 4.5.
- Haiku 4.5 recovered before Opus 4.8 and before the first record closed.
- A second minor Sonnet 5 incident opened at 15:24:05 and resolved at 16:12:32 UTC, leaving a 28-second gap.
- Both records named claude.ai, Console, API, Claude Code and Cowork.
- Anthropic disclosed no shared root cause, affected-user count, data loss, security issue or service-credit outcome.
Twenty-eight seconds is long enough for a status system to close one record and create another. It is too short for most customer queues, workers and monitoring windows to treat the service day as cleanly reset. That difference between record chronology and operational experience is the central fact in Anthropic’s latest incident sequence.
The provider’s evidence remains two separate records. The first concerned Opus 4.8 and Haiku 4.5. The second concerned Sonnet 5. They used the same minor severity and listed the same five surfaces, but Anthropic did not publish a common mechanism.
The first incident recovered by model
The first clock began at 13:37:28 UTC. Its component list covered claude.ai, Console, API, Claude Code and Cowork. Anthropic’s updates showed Haiku 4.5 recovering before Opus 4.8; the overall incident moved to monitoring at 15:06:53 and resolved at 15:23:37.
That staggered recovery matters. A customer able to route work between models may have regained one option while another remained impaired. It also prevents reporting the two models as though they failed equally for the entire record.
The status page supplies state changes, not error percentages. “Minor” is Anthropic’s incident classification. It does not disclose how many users, requests, regions or workloads encountered failure.
The second record reused the service surface
At 15:24:05, 28 seconds after the first resolution, Anthropic opened a record for elevated Sonnet 5 errors. It identified the issue at 15:36:57 and resolved it at 16:12:32. The listed components were again claude.ai, Console, API, Claude Code and Cowork.
Shared surfaces can make different model incidents feel identical to a customer. An application using the API and a developer using Claude Code both encounter the provider through those interfaces. Yet component overlap can arise from a shared dependency, separate model-serving faults exposed through common gateways or status-page grouping. Timing alone chooses none of those explanations.
Calling the whole interval one continuous outage would erase the provider’s separate model records. Treating the 28 seconds as meaningful recovery would overstate what a typical workflow could observe. The disciplined description keeps both layers: adjacent operational disruption, separate causal evidence.
Repeated incidents change the customer control problem
These records followed the four incidents already documented in ewn-093; they are a new recurrence after that article’s cutoff, not a revision of its clocks. The repeated pattern makes customer-side validation more important.
A queue should test successful responses by model and surface before releasing backlog. A fallback policy needs to know whether another model is truly healthy, whether tool calls and workspace functions work, and whether retries risk duplicating actions. Provider resolution is an input to that decision, not its only proof.
The business effect cannot be calculated from public data. Anthropic gave no affected-user denominator, request share, geography, lost work, data-loss report or SLA-credit decision. Any claim that all users were unable to work, that capacity caused the errors or that the same fix handled both records would exceed the evidence.
Better status evidence would connect clocks to exposure
The current pages are strong on precise time and component names. A fuller account would add error-rate ranges, regional or plan scope, model-specific recovery tests and, if established, causal relationships between records.
Until then, the useful conclusion is procedural. Customers experienced almost no clean interval between two model-error records across the same interfaces. Engineers should preserve the two clocks, validate recovery independently and avoid converting adjacency into diagnosis.