Anthropic Outage: Claude 529 overloaded_error, Spend Limits and How to Detect Them

Failure facts checked on the vendor’s docs on Nov 8, 2026.

When Claude calls start failing, the cause is one of two things. Either Anthropic has capacity trouble, or your account has hit a limit. They look alike in a dashboard and need opposite responses. Retrying fixes the first and never fixes the second.

Capacity and outage errors

Anthropic's error reference lists the server-side codes:

• 529 overloaded_error: the API is temporarily overloaded. It can happen during high traffic across all users.
• 500 api_error: an unexpected error inside Anthropic's systems.
• 504 timeout_error: the request timed out. For long Messages requests, Anthropic recommends streaming.

Every error body carries a request_id. Log it. It is what Anthropic support asks for.

Streaming changes the shape. Once the first bytes of a stream are sent the HTTP status is 200, so a later overload cannot change it. Anthropic delivers it as an event: error in the stream with type overloaded_error. A client that only checks status codes counts that call as a success.

async def read_stream(stream, log):
    try:
        async for event in stream:
            ...
    except Exception as err:
        log(kind="stream_error", error_type=getattr(err, "type", "unknown"))
        raise

Spend limits and credit balance errors

These are limit errors, not outages, and they are the ones teams misread as an outage.

1. Organization spend cap: the API returns rate_limit_error with details.error_code set to enforced_spend_limit_reached. Unlike a normal rate limit, there is no retry-after header. Anthropic says retries, including SDK automatic retries, fail until access resumes on the date in the message.
2. A limit you set: HTTP 400 invalid_request_error. The message starts with You have reached your specified API usage limits, or the workspace version of that sentence, and says when access resumes. Raising or removing the limit restores access sooner.
3. Credits used up: requests return Your credit balance is too low to access the Anthropic API. Anthropic says to purchase credits or turn on auto-reload in the Console.

The tell is the missing retry-after, the 400 status, or an exact message string. If you see them, do not page the vendor.

Example: telling them apart

This is an example, not output from a real project.

2026-11-08T10:12:01Z model=claude-main status=529 type=overloaded_error request_id=req_01A attempt=1
2026-11-08T10:12:04Z model=claude-main status=529 type=overloaded_error request_id=req_01B attempt=2
2026-11-08T10:12:05Z model=claude-main status=200 stream_error=overloaded_error tokens_out=212
2026-11-08T10:30:40Z model=claude-main status=429 type=rate_limit_error code=enforced_spend_limit_reached retry_after=none

The first three lines are capacity: retry, then fail over. The third also shows why stream errors need their own field. The last line will repeat until the cap resets, so retrying it only burns time.

What to measure

• Per model: the share of calls ending in 529, 500, 504 or a stream error.
• Separately: any call whose error is a spend limit or credit balance message. One occurrence is worth a ticket, because every later request will fail the same way.
• Retries per call. A rising retry rate is the early sign of overload, before final failures appear.

Start with a page at 5% capacity errors over five minutes, compared with the same hour on previous weeks.

Confirming and responding

The Claude status page has a programmatic API for components and incidents, so you can show open incidents next to your own error rate. During overload:

1. Cap retries, use jittered backoff and honor retry-after on 429s.
2. Queue non-interactive work and shed optional calls.
3. Fall back to a second model if the product allows.
4. For limit errors, raise the limit or add credits, then watch the first calls succeed.

Checklist

• request_id, model, status, error type and error_code are logged on every call.
• Stream handlers log in-stream errors.
• Limit errors have their own alert and are excluded from retries.
• Billing owners see credit balance warnings before an outage.

See vendor degradation detection and third-party failure monitoring. For model spend, see LLM spend spikes. Sazabi can watch these error shares and open an investigated issue when they rise.