← All guides

TroubleshootingUsage limits

Is Claude Code Down? How to Check Status and What to Do During an Outage

By Neo Zino - builder of ClockedCode·Updated October 3, 2026·10 min read

Claude Code is only down for everyone when status.claude.com flags it. Here is how to tell an outage from a local fault, read each error, and keep working.

Made with DispatchSEO

Claude Code is down for everyone only when the Claude Code component on status.claude.com shows an incident. If that page is green and you still cannot work, the cause is a model-level capacity spike, your network, or your own login, and the error text in your terminal tells you which. You can check the status page in about ten seconds, and you can check it from a script too.

TL;DR: Open status.claude.com and read the Claude Code row, not the claude.ai one. Green page plus a connection error means your network. Green page plus 529s means one model is busy, so try /model. Red page means wait, and use --fallback-model or a second provider if you set one up beforehand. Claude Code has already retried 10 times before you see an error.

Is it Anthropic, or is it you?

Start with the status page, because it is the only source that can confirm a service-wide problem. The page lists six components: claude.ai, Claude Console, Claude API, Claude Code, Claude Cowork and Claude for Government. They fail independently. A green claude.ai row says nothing about Claude Code.

Then use the error text to sort the rest. Claude Code's error reference lists the strings, and they fall into two groups:

• Server side: API Error: 500 Internal server error and API Error: Repeated 529 Overloaded errors. Both end with a pointer to status.claude.com.
• Your side: Unable to connect to API, Connection refused, No internet route, and Couldn't connect through your proxy. These never mention the status page, because they are not about Anthropic.

If you are on a different failure entirely, such as the tool not launching or a login loop, that is the Claude Code not working checklist, not an outage.

Ask the status API instead of refreshing a tab

The status page runs on Atlassian Statuspage, which exposes the same data as JSON. I ran both endpoints while writing this:

curl -s https://status.claude.com/api/v2/status.json

{"page":{"id":"tymt9n04zgry","name":"Claude","url":"https://status.claude.com","time_zone":"Etc/UTC","updated_at":"2026-10-03T21:24:33.865Z"},"status":{"indicator":"none","description":"All Systems Operational"}}

status.json only gives you an overall indicator, and none means no incident. For the Claude Code row specifically, use summary.json, which carries one entry per component plus any open incidents:

That output is real, but note what I could and could not verify. I saw the all-green state, because there was no incident during this run. I did not capture a degraded response, so I am not going to show you what a red one looks like in JSON. Statuspage documents indicator values such as minor, major and critical, and each component's status changes from operational when something is wrong. Check the field names against a live response before you build alerting on them.

A one-liner for your terminal, using the standard library only:

curl -s https://status.claude.com/api/v2/summary.json | python3 -c "
import json,sys
d=json.load(sys.stdin)
for c in d['components']: print(c['name'],'|',c['status'])
print('incidents',len(d['incidents']))"

The page also offers email, SMS, Slack, Teams, webhook, Atom and RSS subscriptions. If Claude Code is part of your team's daily work, subscribe a channel once and stop checking by hand.

What each error is telling you

Claude Code retries before it complains. Per its docs, it retries up to 10 times with exponential backoff for server errors, dropped connections, stalled streams and temporary 429 throttles. It does not retry TLS certificate failures, and it keeps partial output if a failure lands mid-block. While it retries you see a countdown such as Retrying in Ns · attempt x/y, so a quiet terminal for a minute is often the retry loop, not a hang.

Two details trip people up. A 529 never counts against your quota, so you are not burning usage while it fails. And a 429 can look like an outage when it is really your own limit, which is a separate problem covered in Claude Code hitting usage limits too fast. For the full story on the overload code itself, see the 529 guide.

What a local failure looks like

I wanted a real example of the "your side" group, so I pointed Claude Code at a port where nothing listens and limited retries:

ANTHROPIC_API_KEY=sk-ant-fake ANTHROPIC_BASE_URL=http://127.0.0.1:9 \
  CLAUDE_CODE_MAX_RETRIES=1 claude -p "hi"

API Error: Connection refused - a firewall or proxy may be blocking it (ECONNREFUSED)

The output (dash replaced with a hyphen here) is what a local network failure reads like: a connection error naming a firewall or proxy, with no mention of capacity or the status page. If you see that on a normal setup, the status page will almost certainly be green, and the fix is on your network. If you are behind a corporate proxy, the Claude Code proxy guide covers the variables. I forced this error myself, so treat it as an example of the shape, not a report of a real outage.

One more check that stays local: claude doctor prints your install method, version and search status, and flags invalid settings. It does not tell you whether Anthropic is up, but it rules out a broken install in seconds.

If it is just slow rather than failing, that is a different question with its own answer in why Claude Code feels slow.

What to do while it is down

Which move helps depends on what kind of "down" you have.

One model overloaded, status green. Run /model and pick another. The error reference says capacity is tracked per model, so Sonnet can work while Opus returns 529. It is the cheapest fix there is.

A real incident. Waiting is legitimate. Meanwhile, do the work that does not need the model: read the diff, write the test names, update the ticket, and draft the next prompt so you can paste it when service returns. Files Claude already wrote are on disk and stay there.

A response that dies halfway. The docs list messages like Connection lost mid-response and Your computer went to sleep mid-response. In an interactive session, read what arrived and reply continue to resume from the last completed block. In -p mode, resume the session and send continue.

An unattended job. Ten retries is not enough for a long incident. Set CLAUDE_CODE_RETRY_WATCHDOG=1. Per the docs it retries 429 and 529 indefinitely and raises the default retry count to 300, roughly three hours of backoff, while spend-limit 429s still fail fast.

Set up a fallback before you need one

An outage is the wrong moment to configure anything. Three layers, cheapest first:

The model chain is the one I would set on every machine. The docs describe --fallback-model as a comma-separated list, and the same chain lives in settings as an array:

{
  "fallbackModel": ["claude-sonnet-5", "claude-haiku-4-5"]
}

When the primary model is overloaded, unavailable, or returns another non-retryable server error, Claude Code switches for that turn and shows a notice. Your next message tries the primary model again. Authentication, billing, rate-limit, request-size and transport errors never trigger a switch, so it will not paper over a network fault or a spend cap.

The second provider is the heavy option, and it only makes sense if you already have the account. Claude Code supports Amazon Bedrock through CLAUDE_CODE_USE_BEDROCK=1 plus AWS credentials and a region, and you should pin model versions in ANTHROPIC_DEFAULT_OPUS_MODEL and friends so aliases do not surprise you. I have not run Bedrock here, so this part is as documented, not as tested. The point is the lead time: AWS model access needs a use-case form and IAM permissions, and none of that is fun mid-incident.

If you want a different tool in reserve entirely, the Claude Code alternatives roundup compares seven. A tuned CLAUDE.md and your hooks do not carry over to them, so treat that as a last resort for a long outage.

When "down" is not an outage

• A single stuck session with a healthy status page. Open a fresh one before blaming Anthropic.
• A login or key problem. A wrong ANTHROPIC_API_KEY in your shell can make every request fail the same way, and it will look like overload.
• A spend or usage cap. That needs a reset or a higher limit, not patience.
• A slow proxy. Raise API_TIMEOUT_MS before you assume the API is the problem.

Status pages also lag. If your terminal says 529 and the page is green, trust the terminal for the next ten minutes and switch models.

FAQ

How do I check if Claude Code is down?

Open status.claude.com and look at the Claude Code component, which is listed separately from claude.ai and the Claude API. If it shows an incident, the problem is on Anthropic's side. If everything is operational, run claude doctor and look at the exact error text in your terminal.

Can Claude Code be down while status.claude.com shows everything operational?

Yes. Status pages are updated by people after an incident is confirmed, so there can be a gap. Capacity is also tracked per model, so one model can be overloaded while the page shows green. If you see repeated 529 or 500 errors with a green page, switch models with /model and retry in a few minutes.

What does API Error 529 Overloaded mean?

It means Anthropic's API is at capacity. Claude Code has already retried up to 10 times with backoff before it shows you the message. A 529 does not count against your usage limit, and it is not caused by your prompt or your setup.

What is the difference between a 529 and a 429 in Claude Code?

A 529 is service-wide capacity strain on Anthropic's side. A 429 is a rate or spend limit tied to your account or credential. Temporary 429 throttles are retried automatically, but a spend-limit 429 is not, and it will not clear until the limit resets.

Can I make Claude Code switch to another model automatically when one is overloaded?

Yes. Start with claude --fallback-model sonnet,haiku, or set fallbackModel in settings.json. When the primary model is overloaded or unavailable, Claude Code tries the fallbacks in order for that turn and shows a notice. Authentication, billing and rate-limit errors never trigger a switch.

Will my work be lost if Claude Code goes down mid-session?

Usually not. If the connection drops mid-response, the partial output stays on screen and you can reply with continue to resume from the last completed block. In non-interactive mode you can resume the session and send continue. Files Claude already wrote to disk stay there.