429 vs 503: Too Many Requests vs Service Unavailable
429 and 503 can look similar in logs, but they tell clients, crawlers, and API consumers different things.
| Aspect | HTTP 429 — Too Many Requests | HTTP 503 — Service Unavailable |
|---|---|---|
| Definition | The server is throttling the client. The Retry-After header, when present, tells the client how long to wait before retrying. | The server is temporarily unable to handle the request. Unlike 500, this is usually a known, often intentional condition. The Retry-After header, when present, estimates when the server will be available. |
| Plain-language summary | The client has sent too many requests in a given time window and has been rate-limited. The server is throttling this client to protect the service. The Retry-After header, when present, specifies how long to wait before retrying. | The server is temporarily unable to handle the request due to overload or scheduled maintenance. Unlike 500, this is often a known, intentional state. The Retry-After header, when present, estimates when the server will be available. |
| When to use | Return 429 when a client exceeds its rate limit. Always include Retry-After when you know the reset time. Include rate limit information in response headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) so clients can self-regulate before hitting the limit. | Use 503 for: intentional maintenance windows, overload shedding when the server cannot handle more requests, circuit breaker tripping on a failing dependency. Always include Retry-After when you know the recovery time. For rate limiting a specific client, use 429 instead. |
| Client behavior | Stop sending requests immediately. Wait for the time specified in Retry-After. Implement exponential backoff if Retry-After is absent. Add rate limit header monitoring to avoid hitting the limit proactively. | Retry after the time specified in Retry-After. If no Retry-After, use exponential backoff. Implement circuit breaker logic to stop sending requests to an endpoint that has been returning 503 repeatedly. |
| Caching behavior | Not cached. Rate limit decisions are per-client and per-window. | May be cached if Retry-After is present, but this is unusual. Generally not cached. |
| SEO / crawler impact | Search crawlers interpret 429 (client-errors) for indexation and link equity accordingly. | Search crawlers interpret 503 (server-errors) for indexation and link equity accordingly. |
| API / backend impact | API clients branching on 429 expect Too Many Requests semantics. | API clients branching on 503 expect Service Unavailable semantics. |
| Safe to retry? | Only after fixing the underlying cause | Yes, with backoff — server may recover |
Common real-world scenarios
When you see HTTP 429
In API gateway logs, 429s indicate: clients not respecting rate limits (missing backoff logic), script/bot traffic hitting public endpoints, or legitimate high-volume clients that need a tier upgrade. Monitor 429 rates per client ID/IP to identify which clients are causing problems.
When you see HTTP 503
During maintenance windows, return 503 with Retry-After so users and crawlers know when to come back. During overload events, load balancers may return 503 when the upstream pool is exhausted. In microservices, a circuit breaker that has tripped returns 503 to downstream services.
Decision rule
Use 429 when the response should communicate too many requests behavior; use 503 when service unavailable is the accurate protocol signal.
A frequent mistake is swapping 429 and 503 for convenience; that causes client retry bugs, incorrect cache signals, and misleading monitoring data.
Use 429 when the correct protocol signal is Too Many Requests. Use 503 when the correct signal is Service Unavailable. Returning either code for the wrong reason breaks client expectations, cache behavior, and monitoring accuracy.
FAQ
What is the biggest difference between 429 and 503?
429 communicates Too Many Requests, while 503 communicates Service Unavailable. Choosing the right one keeps clients and intermediaries predictable.
Do 429 and 503 have SEO or caching impact?
Yes. Search engines and caches interpret status classes differently. Use each code according to its semantics to avoid accidental indexing, stale responses, or crawl inefficiency.
Can APIs safely return 429 instead of 503?
Only when it matches contract semantics. API clients often branch logic by exact code, so swapping them can break retries, auth handling, or user-facing errors.
Full guides
HTTP 429 Too Many Requests — full guide · HTTP 429 status reference · HTTP 503 Service Unavailable — full guide · HTTP 503 status reference · All comparisons