Summary

  • Anthropic classified incident q2kg8n613kr3 as critical and initially moved claude.ai, the Claude API, Claude Code and Claude Cowork from operational to major outage.
  • The provider later bounded elevated error rates across Claude models from 19:45 to 21:26 UTC on 29 July, a 101-minute symptom window.
  • The public incident lifecycle lasted from 19:49:45 until resolution at 22:36:20 UTC, approximately 171 minutes rather than 101.
  • At 21:38 UTC Anthropic reported recovery across most models while elevated requests and latency remained; all four surfaces returned to operational at the 22:20 monitoring update.
  • Anthropic disclosed no root cause, error-code mix, request denominator, customer or regional count, mitigation detail, data-integrity conclusion or post-incident review.
  • GitHub reported a temporally overlapping problem with unnamed external AI model providers, but its record does not identify Anthropic and cannot establish a causal connection.

A wide status record can still be a shallow measurement

The strongest fact in Anthropic’s incident page is breadth. At the investigating update, the structured record changed four components—claude.ai, the direct API, Claude Code and Claude Cowork—from operational to major outage. The incident title eventually described elevated errors across all models, and the provider assigned its most serious public impact label, critical.

None of those fields supplies a denominator. They do not say whether one request in a hundred failed or whether most requests did. They do not show whether the same organisations were affected on every surface, whether failures clustered in one geography, or whether interactive and batch traffic behaved differently. “All models” identifies scope across a catalogue; it does not quantify the share of traffic that each model lost.

The distinction is important because status taxonomies are categorical. A critical label can be useful for escalation, but it is not a percentage, a customer count or a financial measure. Calling the event a total outage would go beyond the record: the updates speak of elevated errors, elevated requests and latency, followed by recovery across most and then all models.

The incident has two defensible clocks

Anthropic opened the public record at 19:49:45 UTC. Its later monitoring note supplied an earlier and more precise symptom interval: elevated error rates ran from 19:45 through 21:26. That is 101 minutes. The page did not move to monitoring until 22:20:16 and was not marked resolved until 22:36:20, roughly 171 minutes after it opened.

Both clocks belong in an operational account. The 101-minute interval is Anthropic’s retrospective boundary for the observed customer-facing symptom. The longer lifecycle captures investigation, identification, partial recovery, monitoring and confirmation. Treating all 171 minutes as continuous elevated errors would overstate the provider’s final wording. Reporting only 101 minutes would hide the time during which customers still had to decide whether recovery was durable.

The intermediate transitions explain the gap. At 20:33, Anthropic said it had identified an issue producing elevated errors across multiple models. At 21:38, it reported recovery across most models, while elevated requests and latency still existed. At 22:20, the four listed components moved from partial outage to operational and monitoring began. Resolution followed 16 minutes later.

Shared surface movement points to a common control plane, not a cause

Four components moved through the same broad states at the same update times. That pattern matters. It suggests that the incident could not be understood as an isolated visual defect on claude.ai or one local workflow failure in Claude Code. Customers entering through an application, an API or an agentic work surface all sat inside the published blast radius.

But synchronised status fields do not reveal architecture. A common model-serving layer, traffic-management system, dependency, release process or status-page convention could produce similar public movement. Anthropic did not name any of them. The evidence therefore supports a shared operational domain, not a technical diagnosis.

This boundary also protects the difference between a model and the system around it. An API request can fail before inference, during streaming or after a successful HTTP response. Claude Code and Cowork add sessions, tools and workflow state above the model call. The incident record does not allocate errors among those layers, so it cannot prove that model weights or outputs were defective.

Retry behaviour can mask impact or multiply it

Anthropic’s general API documentation distinguishes several error families. It describes a 500 response as an internal API error and a 529 response as temporary overload. It also says official SDKs retry transient connection, rate-limit and 5xx failures twice by default with exponential backoff. Those are normal product rules, not a diagnosis of this event: the incident page disclosed no HTTP codes and did not say it was an overload.

The rules still explain why the absent denominator matters. If a first attempt failed but an automatic retry succeeded, an application might record higher latency rather than a visible terminal error. If many clients retried at once, attempted request volume could rise above original business demand. Anthropic’s 21:38 reference to elevated requests and latency is not enough to determine which mechanism dominated.

Customer telemetry therefore needs at least three counters: original business operations, total provider attempts including retries, and terminal failures after retry policy. Without them, a provider recovery can look better or worse depending on where the measurement is taken. Request IDs are equally valuable because Anthropic documents them as the handle for support correlation; aggregated status cannot replace per-request evidence.

Recovery should be proved at the workload boundary

A green provider page is an input to a restart decision, not the whole decision. A team can first send a small set of synthetic requests to the exact model and surface it uses. It can then reopen traffic gradually, monitor latency and terminal error rate, and hold queued work until idempotency and duplicate side effects are understood.

The four-surface scope makes one global health bit especially weak. A short Messages API call may recover before a long Claude Code session or a Cowork workflow becomes reliable. Conversely, an application interface may degrade while a direct API integration remains useful. Customers need probes that represent their actual prompt sizes, streaming behaviour, tool calls and business completion criteria.

Fallback also has a cost. Moving to another model or provider can change output quality, context limits, safety behaviour, data routes and price. An incident plan should state which jobs may be rerouted, which must wait, and how results produced during degraded operation are reviewed. The status record alone cannot make those choices.

Overlapping GitHub times do not name a provider

GitHub opened a separate Copilot incident at 20:07 UTC, within Anthropic’s measured error window. GitHub said requests to specific or external AI model providers were seeing increased errors and that some users could experience failures or degraded performance. It later said the external provider had resolved the issue and Copilot traffic was fully recovered.

That sequence is relevant only as a caution. GitHub did not name Anthropic, publish a model list or disclose a technical cause. Multiple providers can be used by one product, and temporal overlap can arise without a common failure. Joining the two records into an Anthropic-caused Copilot incident would replace evidence with inference.

The disciplined comparison is narrower: downstream platforms can experience provider errors as their own service degradation, while the public chain of dependency remains partly hidden. Better incident disclosure would let customers distinguish a named supplier outage from an independent event without forcing them to correlate clocks.

A useful post-incident account needs rates, layers and actions

Anthropic’s page establishes a credible sequence: critical classification, four shared surfaces, cross-model elevated errors, partial recovery, monitoring and resolution. It does not establish the rate or distribution of failure. A useful post-incident review would add peak and average terminal error rates, the number of organisations or regions affected, the mix of API and application symptoms, and the difference between first-attempt and post-retry outcomes.

It would also identify the failed layer and the remediation. Customers need to know whether traffic routing, capacity, a deployment, a shared dependency or something else changed; whether rollback or failover restored service; and what controls reduce recurrence. Any conclusion about data integrity, safety controls or security should be explicit, because silence is not evidence either of harm or of absence.

The event is therefore material without invented drama. A model provider used as infrastructure suffered a broad, critical incident whose observed errors lasted 101 minutes. Its status machinery showed where the disturbance travelled and when the surfaces turned green. It did not show how many operations failed or why. For customers making resilience decisions, that missing denominator is the central fact.

Sources