# Claude Internal Server Error: Check Status and Retry Safely

> Check the service behind your Claude error, count automatic retries, and choose a safe resend or continuation without repeating completed tool actions.

- URL: https://blog.laozhang.ai/en/posts/claude-internal-server-error
- Published: 2026-07-14
- Updated: 2026-10-04
- Author: LaoZhang AI Team (https://blog.laozhang.ai/en/about)
- Topic: Claude & Anthropic
- Tags: Claude, Internal Server Error, Claude Code, Anthropic API, API Error 500, Troubleshooting

---
For a **Claude internal server error**, check [Claude Status](https://status.claude.com/), then identify where the error appeared. In Claude.ai, preserve your message and try again after a short wait. In Claude Code, read the retained response before resending: a completed tool action may already have taken effect. In an API-backed app, save the returned status, error type, and request ID, and count any retries the app has already made.

A green status page does not prove your request is healthy. Claude's [Help Center](https://support.claude.com/en/articles/12466728-troubleshoot-claude-error-messages) says temporary capacity constraints do not appear on that page. Claude Code can also use a cloud provider or custom gateway with its own service status.

Start with the matching row below. If the work is safe to repeat and no retry is still running, this guide recommends **one deliberate manual retry after the relevant wait**. That is a practical stopping rule, not a universal Anthropic retry policy. If it fails again, preserve evidence and contact the service that can trace the failure.

## Choose the recovery path that matches your error

| Where you see the error | What to check first | Next action | When to stop |
| --- | --- | --- | --- |
| Claude.ai conversation | Claude Status and the exact on-screen message | Save unsent text; wait briefly, then resend once if no response was produced | The same task still fails, or the message names a usage or length limit instead |
| Claude.ai login | Status and whether the failure occurs specifically during sign-in | Try a clean browser session; investigate VPN, extensions, cache, and cookies one at a time | Login keeps failing after a controlled comparison |
| Claude Code terminal | Provider named in the error, retry countdown, and retained output | For a 500 before usable output, wait about a minute and retry; for incomplete output, inspect it and continue from completed work | The error repeats, or an action's completion is uncertain |
| Direct Claude API | HTTP status, `error.type`, retry history, and request ID | Let the configured backoff finish; repeat only within a capped budget and when safe | The same route continues failing after that budget |
| A third-party app or gateway | The app's service owner, route, and available logs | Ask the operator to trace both the app-facing and upstream request | You cannot identify the failed hop or safely repeat the work |

Do not treat a generic “Internal server error” banner as proof that the direct Anthropic API returned `500 api_error`. The app may have simplified an upstream error, or its own server may have failed. A returned HTTP response gives you more precise evidence than the wording alone.

## Claude.ai: preserve the conversation before browser troubleshooting

If the error appeared while chatting, save any unsent text and note the time and error wording. Check the relevant component and active incidents on [Claude Status](https://status.claude.com/). An incident update can tell you the affected service and recovery progress; it cannot promise when your particular conversation will work.

With no posted incident, make a small comparison. After a short wait, try the existing message once. If the original conversation still fails, preserve it and try a short, harmless message in a new chat. A fresh chat succeeding is useful evidence that the failure is narrower than all Claude access. It does not prove the original conversation is corrupted or authorize deleting it.

Follow a more specific message when one appears. The [Help Center](https://support.claude.com/en/articles/12466728-troubleshoot-claude-error-messages) distinguishes:

- **Capacity constraints:** try again in a few minutes. These are temporary load-management conditions and do not appear on the public status page.
- **Usage limits:** follow the reset time or the account's applicable usage option. Repeatedly resending does not restore the allowance.
- **Conversation length limits:** shorten the input, attach fewer or smaller files, or start a new conversation with the necessary context.
- **Login errors:** investigate the sign-in session and browser conditions.

### When should you clear cache and cookies?

Use that step for a browser or login problem supported by the comparison, after saving your work. Anthropic's login guidance includes checking VPN use, disabling extensions, and clearing cache and cookies. Those are login troubleshooting steps, not a documented cure for every server error.

A private window can provide a cleaner comparison before you remove stored session data. If it works, investigate one browser variable at a time. If it fails too, keep the result for support instead of repeatedly clearing data. Browser cleanup will not repair a returned API 500 in your application or a cloud-provider failure in Claude Code.

## Find the provider behind Claude Code or your app

![Claude error surfaces, their service owners, and useful request evidence](https://blog.laozhang.ai/posts/en/claude-internal-server-error/img/surface-owner-map.webp)

For Claude Code, read the **whole error message**, including the service-health sentence. The current [Claude Code error reference](https://code.claude.com/docs/en/errors#api-error-500-internal-server-error) says that sentence follows the configured provider: Anthropic, Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, or the host behind a custom `ANTHROPIC_BASE_URL`.

Check that provider's health information. A green Claude Status page does not clear a Bedrock route, a Google Cloud route, or a gateway you operate. Conversely, a gateway showing 500 does not by itself establish that Anthropic failed upstream.

There is also a useful distinction in the terminal wording. Since Claude Code v2.1.281, a proxy or gateway's HTML error page is shown using its status code and page title, such as `502 Bad Gateway`. An HTML proxy error belongs to that route's investigation; it is not automatically a direct Claude API error object.

If you use Claude through somebody else's app, the app operator is usually the first person who can inspect the route. Provide the time, visible message, and app request ID if one is available. You do not need to create an Anthropic API key to troubleshoot a third-party app's error.

## Claude Code: retry an unfinished request or continue completed work?

**Read what Claude completed before choosing “try again” or “continue.”** The recovery decision depends on how far the response got, not just whether any characters appeared on screen.

Claude Code's [automatic retry documentation](https://code.claude.com/docs/en/errors#automatic-retries) says it retries transient failures up to **10 times** with exponential backoff before showing an error. This is a retry limit, not a claim that every failure makes exactly 10 total attempts. Different failures and stages of a response have different rules.

| Response state when a server error occurs | Current documented behavior | What you should do |
| --- | --- | --- |
| No response has streamed | Applicable transient failures can use the normal automatic retry budget | Let the current retry finish; inspect the final error before manually resending |
| Thinking has finished, but no text or tool call has started | Since v2.1.284, a server error at this point can be retried up to twice | Do not assume thinking alone means a tool already ran; check the final error and version |
| A text or tool-call block has completed, or one has started after thinking finished | Claude Code avoids replaying the original request, retains completed blocks, runs finished tool calls, and continues from their results | Inspect the retained response and actual tool state; continue the remaining work |
| The response already finished | Claude Code keeps the complete response and ends normally | Check the result; do not repeat a finished turn merely because the connection later ended |

These are the current error reference's server-error and recovery rules. Connection drops and stalled streams have their own retry conditions; use their exact displayed message rather than applying the thinking-stage server-error count to every interruption.

### If no usable output was produced

For a displayed `API Error: 500` after applicable automatic retries, Anthropic recommends checking the provider's status, waiting about a minute, then sending the message again. The original prompt remains in the conversation, so you can send `try again` rather than paste a long prompt again. Before doing so, confirm that the earlier turn did not complete an action you would duplicate.

For `Repeated 529 Overloaded errors`, Claude Code has already applied retries. The documented next step is to wait a few minutes and check the named provider's status. You can use `/model` to choose another available model if that fits your task; availability is specific to your access and route. The [Code error reference](https://code.claude.com/docs/en/errors#api-error-repeated-529-overloaded-errors) treats overload separately from usage limits.

### If “The response above may be incomplete” appears

![Inspecting retained Claude Code output, completed tool actions, and evidence before continuing](https://blog.laozhang.ai/posts/en/claude-internal-server-error/img/partial-output-escalation.webp)

Keep the session. The [incomplete-response documentation](https://code.claude.com/docs/en/errors#the-response-above-may-be-incomplete) says Claude Code retains completed blocks but discards an interrupted final block. An unfinished sentence or tool call may therefore be missing. Since v2.1.199, mid-stream server errors at this stage preserve completed output instead of discarding the whole turn.

Check both the transcript and the result of the work. A completed file-edit tool can leave a changed file. A command can have produced files or started a process. An external service can have accepted a deployment, message, or database operation even when the final response never reached you. The stream error does not roll those actions back.

Once the connection is stable, reply `continue` in the interactive session to pick up from the last completed block. If a side effect is uncertain, first ask Claude to identify the completed actions and inspect their results before taking another action. That avoids reconstructing the whole task as if nothing happened. For a more detailed state check, use our [Claude Code recovery and side-effect audit guide](https://blog.laozhang.ai/en/posts/claude-code-500-529-rate-limit).

Non-interactive runs can behave differently. Since v2.1.246, when the main conversation's interrupted response contains text and no tool calls, Claude Code can prompt the model to continue up to three times before surfacing the incomplete-response notice. That is continuation of retained output, not a license to replay a tool-bearing request. Do not add a second executor while the first run is still recovering.

## Direct API: distinguish 500, overload, limits, and timeouts

If your client exposes an HTTP response, retain its exact status and `error.type`. The current [Claude API error reference](https://platform.claude.com/docs/en/api/errors) defines the following branches:

| Response | Meaning on the direct Claude API | Recovery implication |
| --- | --- | --- |
| `500 api_error` | An unexpected internal Anthropic error | Retry with bounded exponential backoff when safe; retain the request ID for persistent errors |
| `529 overloaded_error` | Temporary API overload | Reduce concurrent pressure and back off; use [overload handling controls](https://blog.laozhang.ai/en/posts/claude-api-error-529-overloaded) for repeated failures |
| `429 rate_limit_error` | A rate limit, usage-tier monthly spend cap, or Claude Code workspace spend limit | Read the response and account state; a tier spend-cap 429 has no `retry-after` and continues failing until access resumes |
| `504 timeout_error` | The request timed out during processing | Investigate duration and streaming for long requests before repeating the operation |

A `500 api_error` does not diagnose an invalid prompt, expired key, or empty balance. Those conditions have their own response types. Equally, do not assume every 429 will recover after a short sleep: the spend-cap case requires restored access.

### Count SDK and gateway retries together

Official SDKs retry transient failures **twice by default**, using exponential backoff and honoring `retry-after` when present. The client accepts `max_retries` to change or disable that policy. This SDK policy is separate from Claude Code's retry rules. [Source: API error reference](https://platform.claude.com/docs/en/api/errors).

Your own loop, SDK, and gateway can each issue retries. Before adding another loop, identify which layer controls the budget and record the observed attempts. Cap both retries and elapsed time at the application layer. For work that writes to another system, use a de-duplication record or other protection against repeating an accepted action. A server error alone is not proof that nothing happened.

For production details such as capped retries, circuit breakers, and same-route recovery checks, continue with the [Claude API error 500 guide](https://blog.laozhang.ai/en/posts/claude-api-internal-server-error).

### A stream can fail after HTTP 200

A successful initial HTTP status does not guarantee the response finished. Anthropic documents that an SSE stream can return an error after HTTP 200, so inspecting only the initial status can miss the failure. Handle the stream's error and completion signals, retain any usable output, and verify side effects before restarting a tool workflow. Claude Code's recovery behavior does not automatically apply to an application you built with an SDK.

### Keep the request identifier, not your secrets

The API's `request-id` response header and an error body's `request_id` normally contain the same identifier. Preserve either, and both when your logging already exposes them. Support can use that ID to trace the request. Python and TypeScript response objects expose `_request_id`; exception and raw-response access depend on the SDK. [Source: request ID documentation](https://platform.claude.com/docs/en/api/errors#request-id).

Claude Platform on AWS additionally provides `x-amzn-requestid`, the primary identifier for CloudTrail, with Anthropic's `request-id` as a secondary identifier for Anthropic support. That documented product should not be confused with Amazon Bedrock. Use the identifiers your actual provider exposes.

## Stop retrying and send evidence to the right owner

Stop the manual retry loop when the same route still fails after its budget, a relevant incident is active, or you cannot verify whether an action completed. Preserve the original failure before comparing providers, models, or inputs. A comparison is useful when you change one variable and can explain the result; changing five variables and seeing success does not identify the cause.

For a gateway, collect both the response your app received and the upstream trace the operator can inspect. The gateway might have returned its own error, relayed an upstream failure, or rewritten a timeout. Contact the gateway operator for that boundary, your cloud provider for its managed route, and Anthropic for an identifiable Anthropic request.

A useful support packet contains:

- The time and timezone, exact error wording, and affected app or surface.
- The provider or endpoint owner, model, and client or Claude Code version, when known.
- HTTP status, error type, request ID, and a gateway or cloud trace ID, when available.
- What automatic and manual retries occurred, and whether any completed output or tools remain.
- The status page result at the time and a small, redacted reproduction.

A Claude.ai reader may only have a screenshot, timestamp, and conversation context. That is still useful; do not invent a request ID. Exclude API keys, tokens, private prompts, and customer data from public reports.

For a persistent Claude Code error with no posted incident, the official [500 guidance](https://code.claude.com/docs/en/errors#api-error-500-internal-server-error) recommends `/feedback`; use its “Report an error” guidance if that command is unavailable. A third-party app's support team may need to trace its own request first.

## Frequently asked questions

### Is Claude down right now?

Check the [live Claude Status page](https://status.claude.com/) and the component you use. A previously green snapshot or a resolved incident cannot answer whether your request is failing now. If Claude Code uses another provider, check the health source named in its error too.

### Why does Claude show an internal server error when status is green?

The status page does not verify every request or provider route. Anthropic also says [capacity constraints](https://support.claude.com/en/articles/12466728-troubleshoot-claude-error-messages) do not appear there. Use the exact message and a controlled comparison to choose the next branch; green status alone does not prove a browser fault.

### How long should I wait before trying again?

For Claude Code 500, the [documented advice](https://code.claude.com/docs/en/errors#api-error-500-internal-server-error) is about a minute; repeated 529 and Claude.ai capacity notices call for a few minutes. These are retry intervals, not promised repair times. An active incident's updates are the better source for recovery progress.

### Should I resend a Claude Code request after partial output?

Inspect it first. Completed text or tool blocks change the recovery path: retain the work, check actions, then continue. Thinking alone is different: since v2.1.284, a server error after completed thinking but before any text or tool call can still trigger up to two retries. The [automatic retry rules](https://code.claude.com/docs/en/errors#automatic-retries) describe that distinction.

### Will a new API key or paid plan fix a 500?

A returned `500 api_error` is not evidence that you need either. The [API error reference](https://platform.claude.com/docs/en/api/errors) distinguishes authentication, billing, rate-limit, and internal-error responses. Repair credentials or account access when their own error signals justify it; preserve a persistent 500 for the service owner.

## Sources

External pages this guide links to, in the order they appear. Last updated 2026-10-04.

- [Claude Status](https://status.claude.com/) (status.claude.com)
- [Help Center](https://support.claude.com/en/articles/12466728-troubleshoot-claude-error-messages) (support.claude.com)
- [Claude Code error reference](https://code.claude.com/docs/en/errors) (code.claude.com)
- [Claude API error reference](https://platform.claude.com/docs/en/api/errors) (platform.claude.com)