Is Claude AI down, the per-request view a status page cannot give you

Two questions that look like one

"Is Claude down" is a global question. Either the API is up for everyone, degraded for some, or down for everyone, and the answer lives at status.claude.com. That page lists incidents per surface (Claude.ai, the public API, Claude Code) and per model family (Opus 4.7, Sonnet 4.6, Haiku 4.5). It is the right place to look first and the only place where Anthropic itself confirms or denies an outage.

The question a running tool has to answer is different. It is my single request, right now, this attempt: did it land, did it fail, is the SDK already retrying it on my behalf, and how many seconds until I find out which way it goes. A status page cannot answer that. By the time an incident shows up there, your request has already been retried, succeeded, or terminally failed. The local question runs on a different clock.

Most of this page is about that local clock, because almost no other guide on this topic covers it.

The nine error types Anthropic actually returns

The Anthropic TypeScript SDK ships a strict union for everything its server can hand back. You can read it directly at node_modules/@anthropic-ai/sdk/resources/shared.d.mts line 19. There are nine values, and during a real outage you only see two of them most of the time.

The two you see during an actual incident are overloaded_error (HTTP 529) and api_error (5xx). Everything else either says you, the caller, did something wrong (400, 401, 403, 404), or that your account is at a billing wall (402, 429). Those last five do not move with an Anthropic outage at all. Your tool seeing them more often during a status page red bar is coincidence; they were always going to fire on those specific requests.

What the SDK does without asking you

On a 529 or a 5xx the SDK does not throw immediately. It re-issues the same request a small number of times with exponential backoff, honoring the Retry-After header when the server provides one. Each retry emits a system event the agent host can subscribe to, with five fields the host can show the user.

The five fields are pinned in src/lib/chat-events.ts lines 85 to 91: httpStatus, errorType, attempt, maxRetries, and retryDelayMs. Those are the bytes that walk from Anthropic, through the SDK, through the agent process, into the chat overlay you actually look at while waiting.

Where those bytes actually travel

The path is short and worth seeing in one frame. The hub is the patched ACP wrapper inside the in-VM agent process; without it, two of the four sources go silent.

The five fields cross four process boundaries: from Anthropic over HTTPS into the SDK; from the SDK into the agent runtime as a system event; from the runtime into the bridge as an ACP sessionUpdate; from the bridge into the browser as an NDJSON line on the live response stream. By the time they land, they are still the same five integers and one short string that left Anthropic.

One real outage, message by message

The shape below is what a single user prompt looks like during a mid-grade Anthropic incident: two consecutive 529s, the SDK's own backoff, then a clean stream on attempt three. The Bridge row is the line of code that surfaces each step to the user.

The user's screen during this is not blank. The amber retry overlay (defined in src/app/(landing)/page.tsx around line 511) reads: Retrying request, attempt 2/3 on top, then overloaded_error (HTTP 529) - next in 8s below. When attempt 3 succeeds it disappears and text_delta chunks start flowing. The whole episode reads like a polite pause, not a crash.

Why the stock SDK silence is the worst outage UX

Without a host that listens to the SDK's system events, a 529 wave looks like nothing. The SDK swallows the error, sleeps, tries again, and eventually either succeeds (great, no one needed to know) or gives up (now you have a generic timeout message after half a minute of silence). The user's mental model in that window is wrong: they assume the model is thinking, when it is actually waiting.

The patched ACP entry at src/core/vm-scripts.ts (lines 18 onward, with the api_retry forwarder at lines 112 to 137) wraps the agent loop's system iterator and re-emits five event types the published claude-agent-acp drops on the floor: api_retry, rate_limit_event, compact_boundary, tool_progress, and task_notification. Each becomes a sessionUpdate the bridge can route. The reason this matters during a Claude incident: the difference between "model is thinking for thirty seconds" and attempt 2/3 - overloaded_error - next in 8s is the difference between users hammering the retry button (making things worse) and users waiting one beat (which usually works).

The patch is small. The user-experience delta during a real outage is large.

The 15 second watchdog that catches the SDK's blind spot

One more layer, because the SDK is not infallible. There is a class of failure where the agent process never receives the first chunk: the connection establishes, then the underlying socket stalls, then nothing. The SDK does not always notice in time. The host has to.

src/app/api/chat/route.ts line 421 sets ttftMs = 15_000. If the agent emits zero notifications in that window, the bridge evicts the session, sends an error event with the message Agent did not respond within 15s. Please retry. and captures a chat_ttft_timeout event for telemetry. The next request boots a fresh VM. This is the only path that produces a fast failure during a serious Claude incident, because the SDK's own retry budget plus backoff can chew up half a minute on its own.

Numbers worth remembering

What this means if you are about to ship something on Claude

The thing that breaks user trust during a Claude incident is not the incident. Outages happen on every API; users understand that. What breaks trust is silence. A spinner that has been turning for twenty seconds with no explanation feels like a bug in your product, even when the actual fault is upstream.

Three things to put in your own app, if you are not using mk0r and are wiring Claude in directly:

1. Subscribe to the SDK's retry events. The Anthropic SDK exposes them; do not throw the information away. Show attempt N of M and the next delay.
2. Classify errorType, do not regex the message.The structured field is stable. The message string is not. mk0r's classifyPromptError function shows the shape: status plus type, fall back to regex only when the SDK omits both.
3. Set a TTFT watchdog. Pick a number you can defend (mk0r picked 15 seconds because that is roughly twice the model's normal first-token latency under load). When it fires, fail loudly and quickly so the user can decide what to do next.

None of this stops a real outage. It changes how the outage feels to the user from this app is broken to this is a Claude wave, the app is handling it.

Where to actually look during an incident

For the global question, three sources, in order:

• status.claude.com for official confirmation, per-surface and per-model. This is the record of truth.
• downdetector.comand IsDown for user-report aggregations. Useful for spotting an incident before it's posted on the status page; noisier and less authoritative.
• Hacker News and the Anthropic Discord for the developer-side explanation, often before the postmortem.

For the local question (whether your specific request is stuck), the answer should be inside your own app. If it is not, that is something to fix before the next incident, not during.

Frequently asked questions