What to Do When Claude Is Down

When Claude stops answering, save what you have and stop resubmitting the same task. A half-finished response is inconvenient. Several overlapping agent runs modifying the same files can leave you with a much harder problem.

Open the official Claude status page from Anthropic. Anthropic is Claude's vendor. Check whether the notice concerns Claude web, the API, Claude Code or a narrower issue. If you cannot match your symptoms to a notice, start with Is Claude down?.

Preserve the task before troubleshooting

Copy an unsent prompt into a local note. Save useful response text, record the conversation or request identifier and keep the error. For coding work, save editor buffers and inspect the working tree before closing anything.

Write down the intended next step. A short note such as “tests fail on empty input; inspect the parser before editing” is more useful for resuming than another copy of the entire conversation. Include what was already completed and what you have not verified.

If tools were running, check their state. A terminal process or remote action can outlive the visible assistant response. Stop an operation only when you understand what it is doing and whether interruption is safe. Do not assume a connection error undid its effects.

Confirm the outage and communicate its scope

Match the failed product, model and operation against the incident. Ask one teammate to make a small harmless request if the scope remains unclear. Avoid asking everyone to submit a long generation at once.

Use this message as a starting point:

Claude [web/API/Code] is affecting [task]. We observed [symptom] at [time and timezone]. Anthropic has [confirmed an incident / not published a matching incident]. Please pause [automation or repeated requests]. We can continue [specific work]. [Owner] will check again at [time].

Keep suspected and confirmed impact separate. Downdetector or social reports can help you spot a pattern, but an official incident and your own error details are better references for team decisions. Do not turn an uncertain diagnosis into a broad claim about all Claude products.

Keep working without generation

For development, use the repository you already have. Reproduce the bug, read the relevant code, write a failing test, simplify the issue or review the previous diff. These tasks produce useful evidence for a later assistant session and often resolve the problem themselves.

For writing or analysis, outline the answer, collect source material and mark unresolved questions. Keep facts separate from guesses. The outage is not a reason to turn an unfinished generated paragraph into a verified conclusion.

Another model or provider may be an option if it is already approved for the data and task. Check that it does not rely on the same failing service. Move only the context needed, and evaluate the result again rather than assuming identical capabilities or behavior.

Handle Claude Code as a repository task

Review changed files and compare them with the original request. Run the local checks that are available. Mark incomplete edits, missing tests and commands whose result is unknown. Preserve useful work with your normal local version-control process.

Do not launch another coding agent against the same working tree until you know whether the first one is still active. If you switch to manual editing, leave a clear handoff note describing those changes so the resumed agent does not overwrite them.

If the failure occurred inside Cursor rather than Claude Code directly, the Cursor outage playbook helps separate editor, model and cloud-agent problems. Identify the actual path before changing tools.

Handle API failures without multiplying requests

Classify the error before retrying. Anthropic's API error reference documents transient failures, request identifiers and streaming errors. A stream can fail after its initial successful response, so your application should verify completion rather than treating received text as a finished result.

Use bounded retries for suitable transient failures, increasing the delay between attempts and respecting retry guidance. Check whether your SDK already retries so an outer loop does not multiply attempts unexpectedly. Authentication, permission and invalid-request failures need investigation rather than the same retry loop.

For a customer-facing feature, preserve the user's input and explain the interruption honestly. Do not display an incomplete answer as final. If an AI workflow invokes external tools, reconcile completed actions before replaying it. A duplicate email or order is not fixed by a later successful generation.

Verify recovery before reopening the queue

Follow the incident notes, then test your own workflow. A green headline may not describe every account or pending operation; the shared status-page guide explains that gap.

1. Try one short request in the product and model you need.
2. Confirm that the response completes, including streamed output where relevant.
3. Review unfinished code changes and the results of any tool actions.
4. Resume one saved task with a concise handoff, not a blind replay.
5. Restore background traffic gradually and monitor failures and queue depth.
6. Tell the team what has recovered and which tasks still need review.

Keep the incident note short enough to reuse. Record the useful workaround and any missing error handling you discovered. That gives the next outage a better starting point without turning a temporary problem into an emergency migration project.

An optional break while you wait

Once the work and recovery checks are covered, you can join the Nines ping list. Nines is a small browser arcade that opens during qualifying official developer-tool outages. Yellow or degraded status alone does not unlock it.