Claude resolves two Sonnet 5.5 incidents; the later reported impact window was 35 minutes

Anthropic marked two October 27 incidents involving elevated errors for Claude Sonnet 5.5 as resolved. The later incident report gives an impact window of 14:42–15:17 UTC: 35 minutes at the reported minute resolution. The earlier report does not specify when user impact began or ended.

Both records list claude.ai, the Claude API, Claude Code and Claude Cowork as affected services. At 23:45 UTC on October 27, the official status page showed “All Systems Operational.” That is a dated status observation, not a promise about a later request.

The two records contain different kinds of clocks:

October 27 incident	Provider‑reported impact, UTC	Displayed first → resolved posts, UTC
Earlier incident	Not reported	09:14 → 09:56; 42‑minute display span
Later incident	14:42 → 15:17; 35 minutes	15:09 → 15:50; 41‑minute display span

All times in the table are UTC, and displayed endpoints have minute precision. The notice column measures the span between published updates; it is not a measurement of how long users experienced errors. In the later case, the provider says impact started before its first visible notice and ended before the resolved notice was published.

The underlying post metadata carries seconds: the later first‑to‑resolved publication interval is 41 minutes 8 seconds, and the earlier interval is 42 minutes 11 seconds. Those are still publication intervals. They neither change the later report’s 35‑minute impact window nor establish the earlier impact duration. The records do not support adding the two notice spans into a total for user downtime, and they do not state a root cause.

Anthropic’s error‑message guide distinguishes capacity constraints from service incidents. It describes a capacity message as normal load management when demand is high, and says those capacity issues do not appear on the status page. Service incidents, by contrast, are technical disruptions that make Claude unavailable or significantly degraded for all or most users.

Under that documented distinction, an operational status page and an individual capacity warning can coexist. A green status indicator alone does not diagnose the warning, and a capacity message alone does not establish that either October 27 incident is still active. The exact message, product and time matter when deciding whether a reported incident matches what someone experienced.

The usage‑and‑length guide draws another distinction. Usage limits govern how much someone can interact with Claude over a period of time; usage across claude.ai, Claude Code and Claude Desktop counts toward the same allowance. A warning that gives a session or weekly reset time concerns that allowance, rather than identifying a service failure.

Length limits concern the amount of information Claude can handle within a single conversation. The error guide says a message can exceed that chat’s input limit, including a very large first message. Automatic context management requires code execution to be enabled and does not remove every edge case. Shortening the input or starting a new conversation addresses a different constraint from waiting for an allowance to reset.

For developers whose errors began after changing models, the Sonnet 5.5 migration guide covers request‑setting and response‑parsing changes. Those integration checks answer a different question from the provider’s historical incident clocks. The useful starting point is the actual error and its context—not an assumption that every unsuccessful request has the same cause.

Figure: OpenTools Team, using Claude’s later October 27 incident record. Bars compare the reported user‑impact window with the interval between visible status notices, at minute precision. They measure different events; the notice span is not a second estimate of downtime. The article’s timing table provides the text equivalent.