How to fix: 529 overloaded / service temporarily unavailable
Last verified: June 2026· Anthropic and other providers under load
Where this shows up
Anthropic and other providers under load
How it shows up
The same root cause surfaces in a few different ways. If any of these match, you're in the right place.
- A 529 or equivalent overload response arriving in clusters, affecting many callers at once rather than one workload.
- Requests that succeed on retry a few seconds later with no change to the payload.
- Elevated failure rates concentrated in particular hours, typically the working day of a major time zone.
- Failures on the newest or most in-demand model while an older one in the same family answers normally.
Diagnose it first
Confirm which cause you actually have before changing anything — most wasted time here comes from fixing the wrong one.
| Check | What the result tells you |
|---|---|
| Distinguish 529 from 429 explicitly in your metrics. | They look similar and mean opposite things. A 429 is you exceeding your allocation; a 529 is the provider having no capacity. The first is fixed by changing your traffic, the second cannot be. |
| Check the provider's status page and correlate with your own error timeline. | If the clusters line up with a published incident, there is no bug on your side and the work is entirely about graceful degradation. |
| Test whether an adjacent model in the same family succeeds during the same window. | Capacity pressure is usually concentrated on specific models. If a sibling answers, a fallback chain is the practical mitigation. |
| Confirm what your client does on a 529 today. | Many clients treat it as a generic 5xx and retry immediately, which adds load to an already saturated service and lengthens the outage for everyone including you. |
The fix
- 1Retry with exponential backoff and jitter — the official SDKs do this for 5xx/529 by default.
- 2Add a fallback chain: on repeated overload, route to an alternate model or provider.
- 3Spread bursty traffic over time with a queue rather than firing everything at once.
- 4Monitor the provider’s status page if overloads persist beyond normal blips.
Provider-specific behaviour
The error means roughly the same thing everywhere, but each provider signals it differently.
- Overload is not your quota
- An overload response means shared capacity is exhausted, so raising your own rate limit changes nothing. The levers available to you are patience, a different model, a different region or endpoint where one exists, and degrading the feature gracefully.
- Batch and off-peak work
- Anything that does not have to happen now is worth moving off the peak entirely. Batch endpoints typically run against separate capacity at a lower price, which mitigates overload and cost in the same change.
What doesn't work
Common fixes for this error that look right and aren't.
Retrying aggressively until it succeeds.
Every client doing this makes the saturation worse and prolongs it. It also runs up token spend on attempts that never complete, which is the worst possible way to spend money.
Requesting a rate limit increase.
This addresses the wrong error. Your allocation is not the constraint during an overload, and a higher limit will not conjure capacity that does not exist.
Surfacing the raw error to the user.
A provider-specific status code is meaningless to a customer. A feature that degrades to a queued job, a cached previous answer, or an honest 'try again shortly' keeps the product usable through a dependency's bad hour.
Prevent it
Build fallback chains and request queuing into a gateway so provider load doesn’t become an outage for you.
Common variations and related errors
You'll usually hit this same root cause under a few different names. Same fix.
- "529 overloaded"
- "overloaded_error"
- "API temporarily unavailable"
- "server overloaded"
- "try again later"
Frequently asked questions
What causes “529 overloaded / service temporarily unavailable”?
The provider is temporarily overloaded; this is transient and retryable.
How do I prevent “529 overloaded / service temporarily unavailable” from recurring?
Build fallback chains and request queuing into a gateway so provider load doesn’t become an outage for you.
What is the difference between a 429 and a 529?
A 429 means you exceeded your own allocation and is fixed by changing the shape of your traffic — smoothing bursts, counting retries, splitting keys. A 529 means the provider's shared capacity is exhausted, which nothing you do to your quota will change. Separating them in your metrics matters, because the same retry strategy is correct for one and actively harmful for the other.
How should my client behave during an overload?
Back off substantially with jitter, cap the attempts, and fall back rather than persist. A fallback chain to a sibling model in the same family is the highest-value mitigation, because capacity pressure is usually concentrated on particular models rather than the whole account. Below that, degrade the feature: queue the work, serve a cached previous answer, or tell the user plainly that it will be a moment.
Can I prevent overload errors entirely?
No, and a design that assumes a hosted dependency is always available will fail eventually regardless of provider. What you can do is reduce your exposure — move non-urgent work to batch endpoints and off-peak windows, keep a fallback model configured and tested, and make sure the user-facing failure path is something you would be comfortable with a customer seeing.