Claude Internal Server Error? Check Status, Then Pick the Right Fix

Check Claude Status before retrying. At 10:15 UTC on July 14, 2026, every monitored component was listed as operational; recheck the live page because that snapshot can age. A green page still does not rule out temporary capacity constraints.

Next, identify where the message appeared and who served the request: Claude.ai, Claude Code and its active provider, a direct Anthropic API response, or a provider/gateway route. Count automatic retries and inspect any retained partial output before one manual same-path retry.

The route board below names the health owner, evidence, first safe action, and stop rule for each surface. After that deliberate attempt, stop if the same owned route fails again or the client has already exhausted its retries. Save the UTC time, exact error, provider, model, request ID, and minimal reproduction instead of sending the request again.

Fix a Claude internal server error in the first minute

The visible phrase Claude internal server error does not identify one cause. It can describe a temporary Claude.ai capacity constraint, a Claude Code provider failure, a direct Anthropic API 500 api_error, or an error returned by your gateway. Pick the row that matches the surface you can actually observe.

Before using the table's one-retry allowance, count what the client already did. A manual retry is not “attempt one” if Claude Code, an SDK, a gateway, or your own wrapper has already sent the request several times.

A green status page does not prove the fault is local

Claude's Help Center separates temporary capacity constraints from outages. Capacity constraints can be brief, may affect only part of the service, and may not appear on the public status page. That is why “status is green” should narrow your investigation, not end it with “my browser must be broken.”

The status history also needs careful reading. The most recent incident visible during this review—elevated errors on Claude Haiku 4.5 on July 13, 2026—was resolved. A resolved incident can explain reports that linger in forums or issue trackers, but it is not evidence of an active outage today.

Use a controlled comparison instead of a local-fault guess:

• If Claude.ai fails in one old conversation but a fresh chat works, keep the old thread and treat its state or context as a branch clue.
• If Claude Code fails only on Bedrock, Vertex AI, Foundry, or a custom base URL, check that provider before changing Anthropic account settings.
• If a direct API call returns an HTTP status, error body, and request ID, stay in the returned-API-error branch.
• If no response status, body, or request ID exists, investigate connection, proxy, DNS, TLS, firewall, or timeout behavior instead of calling it a confirmed API 500.
• If the same account fails across Claude.ai, Claude Code, and a direct route at the same time, the evidence points more broadly—but live status and provider ownership still decide who should investigate.

Change and record one variable per comparison. The result does not prove a root cause by itself; its value is removing the wrong branches without destroying the original failure evidence.

Find the service that actually owns the failure

The surface you see and the service that owns the request are not always the same. This is especially important in Claude Code. Anthropic's Claude Code error reference tells users to check the health source for the configured provider: Anthropic, Amazon Bedrock, Google Vertex AI, Microsoft Foundry, or the service behind a custom ANTHROPIC_BASE_URL.

That provider split prevents several bad fixes. A Bedrock-side failure is not repaired by clearing Claude.ai cookies. A gateway mapping problem is not repaired by rewriting a prompt. A direct 500 api_error is not evidence that an API key is invalid or billing is empty. And a green Claude Status page does not certify a third-party provider route.

For Claude.ai, the owner is simpler but the symptom still matters. A normal conversation error should get a short wait and one controlled comparison. A login-specific generic error can justify the Help Center's browser checks—VPN, extensions, cache, cookies, or a private window—but only after status and capacity have been considered. Do not make “clear everything” the first move for every internal server message.

For a gateway, record both sides of the boundary. Capture the downstream response your application received and the upstream request identifier or route log the provider exposes. If you compare against direct Anthropic access, keep model intent, prompt, input size, timeout class, and environment stable. A route comparison is useful only when it is actually comparable.

Classify the response before spending another retry

The official Anthropic API error reference distinguishes errors that are often collapsed into “Claude is broken.” Keep the exact type when you have a real HTTP response.

Do not apply this taxonomy to every web or terminal message. 500 api_error belongs to a direct API response or a client exception that exposes the returned status and error type. Claude Code may display API Error: 500, but its recovery path also includes provider ownership, automatic retries, session state, and partial output. Claude.ai does not give you permission to invent an API error type from a generic message.

Count automatic retries before manual retries

Anthropic's official SDKs retry transient failures twice by default. A raw HTTP client may not retry at all; a wrapper or gateway may add its own policy. Claude Code uses exponential backoff for many transient failures and can make up to 10 automatic attempts before it surfaces the final error. By the time you see a persistent 500, “click retry again” may be attempt eleven rather than attempt one.

That is why the safe budget is expressed as a decision, not an invitation:

1. Inspect the client, SDK, gateway, and application retry history.
2. Decide whether repeating the work is idempotent or otherwise protected from duplicate side effects.
3. If no automatic retry remains in flight and the work is safe, make one deliberate same-path attempt.
4. If it fails, stop and preserve evidence.

For side-effecting workflows, the server error alone may not tell you whether downstream work happened. Use your own idempotency key, de-duplication record, or job state before repeating a charge, write, notification, deployment, or external tool action.

Claude Code: inspect partial output before replaying the turn

Claude Code deserves its own safety check because it can stream text and invoke tools. The current error reference says transient failures are normally retried automatically. After a displayed API Error: 500, wait about a minute and retry the existing message once. If the same error persists, use /feedback with the relevant evidence.

There is one important exception to blind replay. From Claude Code v2.1.199, if a server error happens after partial output has streamed, Claude Code keeps that output instead of automatically retrying it. This avoids duplicate tool calls. Read what was retained before you resend anything:

• Did Claude already propose or issue a tool call?
• Did the tool, shell command, file edit, deployment, message, or external action actually run?
• Is the visible response incomplete but the underlying side effect complete?
• Can you use continue to resume from the retained work instead of repeating the original instruction?

Not every failure retains partial output. The point is to check, not to assume. When no tool action ran, built-in retries are exhausted, and the task is safe to repeat, one deliberate retry can be reasonable. When a non-idempotent action may have run, verification comes before retry.

For the full terminal-specific path—including provider health, the displayed error, wait-and-retry behavior, and support handoff—use the focused Claude Code API Error 500 guide. The broad router stops at that handoff instead of duplicating the terminal playbook.

Direct Anthropic API: preserve both request IDs

A direct Anthropic API 500 gives you stronger evidence than a generic UI message. Preserve the HTTP status, the response body's error.type, its message, the response request_id, and the request-id header. Anthropic documents request IDs specifically so support can trace individual calls.

A compact failure record should look like this conceptually:

text
time_utc: 2026-07-14T10:15:57Z
surface: direct Anthropic API
http_status: 500
error_type: api_error
request_id_body: req_...
request_id_header: req_...
model: <exact model ID>
sdk_and_version: <client + version>
automatic_retries: <observed count>
manual_retries: 0 or 1
repeat_safe: yes / no / unknown

Do not include the API key, full private prompt, customer data, or an unredacted environment dump. Support needs a trace handle and a reproducible shape, not your secrets.

If your confirmed branch is a returned direct API 500 api_error, continue with the deeper Claude API error 500 guide. It covers production retry budgets, same-path verification, circuit breaking, and direct API escalation without forcing those implementation details onto Claude.ai and Claude Code readers.

Provider and gateway routes need two-sided evidence

A provider or gateway can fail before, during, or after its upstream Anthropic call. The message visible to your application may be the gateway's 500, an upstream Anthropic 500 passed through, a timeout rewritten as 500, or a provider-specific capacity response. The status owner and retry owner may therefore be different.

Collect these pairs:

Then ask one question: which owner can trace the failed hop? Contact Anthropic for a traceable Anthropic request, the cloud provider for its managed route, or the gateway operator for mapping, proxy, and upstream evidence. Do not send all three a generic screenshot and hope one recognizes it.

Build an evidence packet that can close the incident

When the same owned route fails after the bounded retry decision, record:

• UTC timestamp and timezone
• visible surface: Claude.ai, Claude Code, direct API, or provider/gateway
• exact error string, HTTP status, and official error type when available
• active provider and route, including custom base URL ownership without exposing credentials
• exact model ID and client, SDK, or Claude Code version
• automatic and manual retry counts
• whether partial output or a tool action was retained
• request-id, request_id, provider route ID, or both sides of a gateway trace
• the smallest redacted reproduction
• status page result and relevant incident link at the failure time
• impact in one sentence

This packet also defines the escalation boundary. Escalate when an active incident says to wait, the same owned route repeats after its safe budget, Claude Code has surfaced the final error after automatic retries, or a partial-output/tool boundary makes another attempt unsafe.

Frequently asked questions

Is Claude down right now?

At 10:15 UTC on July 14, 2026, Claude Status listed every monitored component as operational. That is a timestamped snapshot, not a permanent answer. Check the live page again and then apply the capacity and provider-route checks above.

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

Temporary capacity constraints may not count as an outage or appear on the public status page. A green page also does not verify your exact Claude Code provider, direct API route, gateway, web session, model, or account path.

Does an internal server error mean my prompt or API key is wrong?

Not by itself. A returned 500 api_error is an unexpected API-side error, not a prompt-validation or authentication diagnosis. Preserve the exact response. Move to prompt, auth, billing, or key repair only when their own signals point there.

Should I clear cache and cookies first?

No. Use browser cleanup for a Claude.ai login or session branch after checking status and capacity. It is a poor first move for Claude Code, a direct API response, or a provider/gateway 500.

How many times should I retry?

Count automatic retries first. Official SDKs retry transient failures twice by default, and Claude Code can already have made multiple attempts. If the work is safe to repeat and no retry is still in flight, allow one deliberate manual same-path attempt, then stop and collect evidence.

What should I do with partial Claude Code output?

Read it before resending. Verify whether a tool or external action already ran. Use continue when it can safely resume the retained work. Blind replay can duplicate a non-idempotent action.

Who should receive the support ticket?

Send it to the owner that can trace the failed hop: Anthropic for a direct traceable request, the configured cloud provider for Bedrock/Vertex AI/Foundry routes, or the gateway operator for its route and upstream mapping. Include identifiers from both sides when a gateway sits in the middle.

The working rule

A Claude internal server error is a routing decision before it is a fix list. Check live status, keep temporary capacity distinct from an outage, identify the surface and provider, count retries, protect partial output, make at most one safe deliberate attempt, and escalate with traceable evidence.