Status and reliability
How the gateway handles upstream failures, and what to do when something is degraded.
How failover works
Requests are distributed across upstream capacity. When one upstream returns an error or is overloaded, traffic moves to another rather than surfacing a hard failure — which is why a 529 here is rarer than calling a single provider directly.
What each failure means for you
| You see | Where the fault is | What to do |
|---|---|---|
529 overloaded | Upstream capacity | Retry with backoff; usually clears in seconds |
500 | Gateway | Retry once, then report with the request id |
429 | Your account's concurrency | Reduce parallelism — Rate limits |
| Slow first token | Upstream queueing under load | Expected during peaks; streaming makes it visible sooner |
Building for degradation
- Retry
429,500,502,503and529with exponential backoff and jitter. - Keep a fallback model configured — degrading from Opus to Sonnet beats returning an error.
- Set timeouts so a stalled request cannot hold a worker indefinitely.
- Run the
/v1/modelshealth check in CI so a broken credential is caught before deploy.
For an incident affecting your account, contact support@claudeapikey.dev with timestamps and a request id.