Claude Outage Runbook: 429, 529 and EU Fallback

TL;DR

A Claude outage shows up as 529 (overloaded), 500 or 504. A 429 is usually your own quota. Retry both with backoff and jitter, but never retry a spend-cap 429. For EU data, fail over between the Bedrock EU geo profile and the Vertex eu multi-region. The Anthropic API is not an EU fallback: it has no EU inference geo.

Which Claude error means what during an outage?

Three groups matter. 529, 500 and 504 mean the provider has a problem, so retry and fail over. 429 means you hit a limit: a rate limit you can retry after retry-after, or a spend cap you cannot retry at all. 400, 401, 403 and 413 are your bugs, and a fallback only hides them.

The Claude API errors page describes 529 overloaded_error as the API being temporarily overloaded, something that can happen when traffic is high across all users. It also warns that a sharp increase in your own usage can trigger 429s from acceleration limits. Bedrock and Vertex wrap the same models in their own error vocabulary, so the on-call engineer needs one table, not three docs tabs.

Code	Where	What it means	Action
429 rate_limit_error	Claude API	RPM, ITPM or OTPM limit hit	Wait for retry-after, then retry
429 with enforced_spend_limit_reached	Claude API	Monthly tier spend cap reached	Do not retry. Raise the tier or fail over
400 invalid_request_error	Claude API	Bad request, or a spend limit you set yourself	Fix the request or raise your limit
500 api_error / 504 timeout_error	Claude API	Internal error or timeout	Retry with backoff; for long jobs use streaming
529 overloaded_error	Claude API, Bedrock	Provider capacity, not your quota	Retry with jitter, then fail over
429 ThrottlingException	Bedrock	Account quota exceeded	Backoff, quota increase, or second route
503 ServiceUnavailable	Bedrock	High demand in the Region	Backoff, cross-Region inference
429 “Resource exhausted, please try again later.”	Vertex	Shared pay-as-you-go capacity used up	Truncated exponential backoff, then fail over

Two details change the runbook. The rate limits page says the spend-cap 429 has no retry-after header and keeps failing until 00:00 UTC on the first day of the next month. The caps are 500 USD on Start, 1,000 USD on Build and 200,000 USD on Scale. And the Bedrock error code reference is explicit that a 503 is not related to your account quotas, which return 429. Read the status code before you open a ticket.

How should you retry 429 and 529 errors?

Retry in the SDK, not in a hand-written loop. The Anthropic SDKs already retry connection errors, 408, 409, 429 and every 5xx (which includes 529) twice with short exponential backoff and honour retry-after. Raise max_retries moderately for batch jobs, keep it low for user-facing calls, and add jitter if you run many workers.

The Python SDK page documents the defaults: 2 retries and a 10-minute request timeout. Retries cannot fix a limit that is too small. Rate limits use a token bucket, and Anthropic notes that 60 RPM may be enforced as 1 request per second, so a burst of 20 parallel calls can get throttled even when the minute total looks fine. On the Start tier, Sonnet 5 and Opus 5.5 each allow 1,000 RPM, 2,000,000 input tokens per minute and 400,000 output tokens per minute. Cached reads do not count toward ITPM for most models, which makes prompt caching the cheapest capacity increase you can buy.

import anthropic

# User-facing path: fail fast, let the fallback route take over
interactive = anthropic.Anthropic(max_retries=2, timeout=60.0)

# Batch path: more patience, same client class
batch = anthropic.Anthropic(max_retries=6)

try:
    msg = interactive.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": "Summarise this ticket."}],
    )
    print(msg._request_id)
except anthropic.RateLimitError as e:
    # Spend cap: no retry-after, retrying is pointless
    print(e.status_code, e.response.headers.get("retry-after"))

AWS recommends exponential backoff with random jitter for 429, 500, 503 and 529 on Bedrock, and adds a warning that synchronized retries from many clients slow recovery. Google’s 429 page says the same for Vertex. One trap on AWS: NAT gateways, VPC interface endpoints and Network Load Balancers drop idle TCP connections after 350 seconds, while Linux keep-alive defaults to 7,200 seconds. Long streaming calls then die silently and look like an outage. The fix is tcp_keepalive=True in the boto3 config plus a kernel keep-alive below 350 seconds.

Which fallback keeps Claude inside the EU?

Bedrock with the eu. geo inference profile and Vertex with the eu multi-region. Both serve current Claude models, both keep processing inside EU regions, and both cost 10% more than their global routes. The Anthropic API is not an EU fallback: inference_geo only accepts us and global, and workspace geo is US only.

That last point surprises many teams. The data residency page lists exactly two inference geos. A fallback to api.anthropic.com therefore moves EU personal data out of the EU during the incident, which is exactly when nobody is thinking about GDPR. Global routes on Bedrock and Vertex do the same. Google’s own first tip against 429s is “use the global endpoint”. For EU data, skip that tip.

Route	Model ID	Residency	Documented capacity
Bedrock EU geo profile	eu.anthropic.claude-opus-5-5, eu.anthropic.claude-sonnet-5	EU regions	Default 2M input TPM, up to 5M input and 500k output TPM on request
Vertex eu multi-region	claude-opus-5-5, claude-sonnet-5	EU multi-region	Opus 5.5: 1,000 QPM, 10M input TPM. Sonnet 5: 1,250 QPM, 12.5M input TPM
Bedrock global, Vertex global	global. prefix, region="global"	Worldwide	Vertex Opus 5.5 global: 2,000 QPM
Claude API	claude-opus-5-5	global or us only	Tier limits above

The two EU routes fail independently because they run on different clouds and different quota systems. Two caveats from the AWS cross-Region inference docs: your SCPs must allow every destination Region in the profile, or the geo profile itself breaks, and CloudTrail logs every request in the source Region with additionalEventData.inferenceRegion showing where it ran. Keep that field in your evidence for the data protection officer. The Bedrock and Vertex setups are covered step by step in our guides on Claude on Bedrock in the EU and Claude on Vertex AI in Europe.

Do not confuse this with Anthropic’s fallbacks request parameter. The refusals and fallback page says only a safety classifier decline triggers it, and that a rate limit, overload or server error is returned as-is. It is also not available on Bedrock or Google Cloud. It is a refusal tool, not an outage tool.

Client-side, the fallback is a short loop over two clients:

import anthropic
from anthropic import AnthropicBedrock, AnthropicVertex

ROUTES = [
    (AnthropicBedrock(aws_region="eu-central-1", max_retries=2), "eu.anthropic.claude-sonnet-5"),
    (AnthropicVertex(project_id="my-eu-project", region="eu", max_retries=2), "claude-sonnet-5"),
]
FAILOVER = (anthropic.RateLimitError, anthropic.InternalServerError, anthropic.APIConnectionError)

def ask(messages, max_tokens=1024):
    last = None
    for client, model in ROUTES:
        try:
            return client.messages.create(model=model, max_tokens=max_tokens, messages=messages)
        except FAILOVER as e:  # 429, 5xx incl. 529, network
            last = e
    raise last

400, 401 and 403 are deliberately not in FAILOVER. A broken request fails on both clouds, and an auth error on one cloud is a config problem you want to see, not mask.

With a gateway, the same logic moves into config. LiteLLM falls back to the next model group once num_retries is exhausted, and its fallback docs state that this covers 429 and 500 errors. LiteLLM resolves the location eu to aiplatform.eu.rep.googleapis.com. Our LiteLLM EU gateway guide covers the base install.

model_list:
  - model_name: claude-eu
    litellm_params:
      model: bedrock/eu.anthropic.claude-sonnet-5
      aws_region_name: eu-central-1
  - model_name: claude-eu-vertex
    litellm_params:
      model: vertex_ai/claude-sonnet-5
      vertex_ai_project: my-eu-project
      vertex_ai_location: eu

litellm_settings:
  num_retries: 2
  allowed_fails: 3
  cooldown_time: 30
  fallbacks: [{"claude-eu": ["claude-eu-vertex"]}]

allowed_fails and cooldown_time are the documented example values, a sane start. Every spend log row records attempted_fallbacks and original_model_group, so you can later count how many requests the backup served. Since LiteLLM v1.85.0 the mock_testing_fallbacks flag is stripped from Proxy requests. Test the fallback by breaking the primary in staging, for example with a wrong Region or a revoked IAM permission.

What is the incident runbook, step by step?

Detect with your own error-rate alert, confirm on the right status page, switch routes deliberately, and write down request IDs as you go. Most lost time in a Claude incident is spent on the wrong status page or on retrying a spend cap. The numbered runbook below fits on one screen and works at 3 a.m.

status.claude.com lists claude.ai, Claude Console, Claude API, Claude Code, Claude Cowork and Claude for Government. Bedrock and Vertex are not on it. In September 2026 the page logged 13 incidents, 8 of which touched the Claude API component, mostly elevated errors for specific models. An incident there does not prove Bedrock is down, and a Bedrock problem will not appear there. Subscribe on-call to all three: the Claude status page (email, SMS, Slack, Teams, webhook or Atom), the AWS Health Dashboard and Google Cloud Service Health.

1. Alert. Page on-call when the 5xx plus 429 rate on Claude calls exceeds your threshold for 5 minutes, split by provider and model.
2. Classify. Read the status code and body. Spend cap (enforced_spend_limit_reached) or 4xx: stop retrying, escalate to the budget owner. 429 throttling, 503, 529: provider or capacity.
3. Locate. Check status.claude.com, AWS Health and Google Cloud Service Health. Note whether one model, one route or everything is affected.
4. Fail over. If the gateway has not already switched, move traffic to the other EU route. Never to a global route or api.anthropic.com for personal data.
5. Shed load. Pause batch jobs, lower concurrency, and switch non-critical features to a smaller model on the same EU route.
6. Communicate. First internal update within 15 minutes: impact, route in use, next update time. Repeat every 30 minutes. Customers hear about it only if the switch failed.
7. Collect evidence. Keep request-id values from failed Claude API calls, AWS request IDs and timestamps. AWS asks for request ID, model ID, Region and timestamp in a 529 ticket.
8. Recover. Move traffic back only after the primary has run clean for 30 minutes, to avoid flapping.
9. Post-mortem. Within 5 working days: timeline, how many requests ran on the backup, cost delta, and one change to quotas, alerts or config.

The 15 and 30 minute intervals are our recommendation, not a provider requirement.

Run it yourself or outsource?

Run it yourself if you already have a 24/7 on-call rotation and accounts on both AWS and Google Cloud. Building the fallback is a few days of work. Owning it is the expensive part: quota reviews, drills, model ID changes and post-mortems. Outsource when Claude traffic is business-critical but nobody is on call at night.

What running it in-house actually involves:

Task	Who	How often
On-call for Claude routes	Platform or SRE rotation	24/7 if Claude is customer-facing
Quota reviews, AWS increase requests, Vertex QIRs	Platform owner	Every model launch, at least quarterly
Failover drill in staging	Platform engineer	Quarterly (our recommendation)
Model ID sync across both clouds	Platform engineer	Every launch (Opus 5.5 reached Vertex on 22 September 2026)
Post-mortem and status communication	Incident commander	Per incident

Our estimate, not a sourced figure: 2 to 4 engineer-days to build and test the dual-cloud route, then roughly half a day per month for drills, quota checks and model updates, plus the on-call allowance. If your company has no night rotation, the real cost is the rotation, not the code.

Outsourcing to a managed service provider makes sense when Claude sits in a customer-facing flow and you lack night coverage, or when you would need to open a second cloud only for the fallback. It makes little sense for internal tools where a two-hour outage is an annoyance, or when a provider would route traffic through its own accounts and so change who processes the data.

What to demand from a provider for this topic:

• SLA with realistic scope. Response times per severity for detection and failover. A provider cannot promise capacity that AWS or Google does not, and Google excludes pay-as-you-go 429s from its SLA error rate.
• DPA and subprocessors. A data processing agreement under Art. 28 GDPR, and a subprocessor list that names AWS and Google with the exact Regions. Check that no global route or Anthropic API fallback appears anywhere in their config.
• Access model. They operate in your AWS and Google Cloud accounts through assumed roles with least privilege, read your logs, and do not copy prompts into their own systems.
• Exit. Gateway config, alert rules and runbook live in your repository. Keys and quotas stay in your accounts, so you can take over on a day’s notice.

Pricing context for the 10% regional premium on both EU routes is in our Claude API pricing comparison.

FAQ

Is a Claude 529 error my fault?

No. A 529 overloaded_error means the provider is temporarily short of capacity. It is not your quota, which returns 429. Retry with backoff and jitter, and fail over to your second EU route if 529s continue for more than a few minutes.

What is the difference between a 429 and a 529 from Claude?

A 429 means you hit a limit: rate limit, acceleration limit or spend cap. A 529 means Anthropic or the cloud provider is overloaded for everyone. A 429 rate limit clears after retry-after. A spend-cap 429 does not clear until the next month or a higher tier.

Does the EU fallback cost more than a global route?

Yes. Regional and multi-region endpoints on Bedrock and Vertex carry a 10% premium over global endpoints for current models. US-only inference on the Claude API is priced at 1.1 times standard. During an outage the backup route bills at its own rates, so budget both.

Can I fall back to the Anthropic API and still keep data in the EU?

No. The Claude API supports inference_geo values us and global only, and workspace geo is US only. For EU residency, the fallback pair is Bedrock with an eu. profile and Vertex with the eu multi-region.

Does Anthropic’s fallbacks parameter help during an outage?

No. It retries a request only when a safety classifier declines it. Rate limits, overload and server errors on the requested model are returned to you unchanged, and the parameter is not available on Bedrock or Google Cloud.

Where do I check whether Claude is down?

status.claude.com for the Claude API, claude.ai and Claude Code. Bedrock and Vertex are not listed there, so check the AWS Health Dashboard and Google Cloud Service Health as well. Your own error-rate metrics are faster than any status page.

How many retries should I configure?

Keep the SDK default of 2 for user-facing calls so the fallback route takes over quickly. Raise max_retries for batch jobs that can wait. Never retry a spend-cap 429, and never retry 400, 401 or 403.

Sources

1. Anthropic docs: API errors (1 October 2026)
2. Anthropic docs: Rate limits (1 October 2026)
3. Anthropic docs: Python SDK (1 October 2026)
4. Anthropic docs: Data residency (1 October 2026)
5. Anthropic docs: Refusals and fallback (1 October 2026)
6. Anthropic docs: Claude in Amazon Bedrock (1 October 2026)
7. Anthropic docs: Claude on Google Cloud (1 October 2026)
8. AWS: Troubleshooting Amazon Bedrock API error codes (1 October 2026)
9. AWS: Cross-Region inference (1 October 2026)
10. AWS: Geographic cross-Region inference (1 October 2026)
11. AWS: Claude Opus 5.5 model card (1 October 2026)
12. Google Cloud: Error code 429 (1 October 2026)
13. Google Cloud: Claude Opus 5.5 (1 October 2026)
14. Google Cloud: Claude Sonnet 5 (1 October 2026)
15. LiteLLM docs: Fallbacks (1 October 2026)
16. Claude status page (1 October 2026)