Is Claude down? How to tell, and what to do next

The fastest answer is the Claude status page on isuptime, which reads Anthropic's own feed every few minutes and says what it currently reports.

The more useful answer is that Claude incidents are almost never "Claude is down". They are one surface, or one model, and the status page is built to say which.

What Claude actually reports on

Six components, each with its own status:

The dependency worth noticing: Claude Code is a client of the API. An API incident takes Claude Code with it, and the reverse is not true. If Claude Code is failing while the API component is green, look at your own environment — auth, network, version — before you look at Anthropic.

Incidents are scoped to models, not to Claude

This is the part that surprises people. Read the recent incident titles: "Degraded performance for Claude Opus 5 and Claude Haiku 4.5", "Elevated errors for Claude Fable 5", "Degraded performance for Claude Opus 5, Claude Sonnet 5", "Elevated errors on Google connectors".

Different models run on different capacity. One can be degraded while another is entirely fine, which means the most effective mitigation during a Claude incident is usually not waiting — it is changing the model string. If Opus is throwing errors and Sonnet is not, a one-line config change gets you working again, and it is available to anyone whose code does not hardcode a single model in twelve places.

That is a design decision you make before the incident, not during it.

Two errors that mean opposite things

Both look like failure. They call for opposite responses.

• 429 — rate limited. You are asking for more than your organisation's limit allows. Backing off works. Retrying immediately does not, and makes it worse.
• 529 — overloaded. Anthropic's capacity is saturated. This is not about your account. Retry with exponential backoff and jitter; it usually clears on its own, and it is the error most likely to be accompanied by a status-page incident.

The failure mode to avoid is the retry loop that treats every error identically and hammers a struggling service — the thundering herd that turns a five-minute wobble into a long one for everybody.

Five failures that impersonate a Claude outage

These account for most of the times the status page is green and you are still stuck.

1. Streaming cut by your own infrastructure. Long responses are long-lived connections, and proxies, load balancers and serverless function timeouts kill those on a schedule. A response that always dies at the same elapsed time is being cut by something with a stopwatch, and that something is usually yours.

2. Context window, not capacity. A request that exceeds the model's context is a hard error regardless of how healthy anything is. It shows up the day a document got longer or a conversation got deeper — and it never appears on a status page.

3. Credits and organisation limits. Exhausted credit, a spend cap, an expired key or a per-organisation limit produces a clean rejection that has nothing to do with service health.

4. A model name that moved. Model ids get deprecated. Pinning to one forever means one day the request is for something that no longer exists, and the failure is permanent rather than transient.

5. Connectors and tools. Anthropic's own incident list includes "Elevated errors on Google connectors" — a failure in something Claude reaches out to, not in Claude. If a tool call is what is failing, the question is whose tool.

Is it Claude, or is it just me?

A decision procedure that resolves this quickly:

1. Check the status page and find which component. claude.ai down with the API green means your product is fine and your browser tab is not.
2. Read the error code. 429 and 529 mean different things and want different responses.
3. Try a different model. If one works and another does not, you have both diagnosed the incident and fixed it for now.
4. Try one request by hand with curl, outside your app. If that works, the problem is in your code path.
5. Check whether anything else is broken. If several unrelated providers are reporting problems at the same moment — including other AI APIs — the common cause is more likely upstream, a cloud region or a CDN, than each of them independently having a bad day.

That last step is most of why isuptime reads 102 status pages on one schedule rather than one at a time. Shared timing across unrelated providers is real evidence of a common cause. It is never proof of one.

What to do before it happens

Model APIs fail differently from databases. They rarely go hard down and frequently go slow, and slow is the case most code handles worst: no timeout, no fallback, a queue that grows until something upstream gives up.

The preparation that pays for itself is unglamorous. Put the model id in configuration rather than in code, so switching is a deploy and not a refactor. Set a timeout that reflects a real user's patience rather than the default. Decide in advance what a degraded answer looks like — a cached response, a smaller model, an honest "try again in a minute" — because the alternative is deciding it at the worst possible time.

---

Live Claude status on isuptime is read from Anthropic's own public feed on a fixed schedule and shows what Claude is currently reporting, with the timestamp of the check. It is not an independent test of whether Claude works for you — here is exactly what it can and cannot tell you.