HTTP 503 vs 429: Which One Is Your Rate Limiter Actually Speaking

A rate limiter that returns 429 is doing its job, and a rate limiter that returns 503 is hiding a different failure behind a lie of a status code — the first describes a client that asked too often, the second describes a server that could not answer, and confusing them sends your retry logic after the wrong fix.

That redefinition is what makes the choice tractable. A 429 Too Many Requests is a contract: the service is healthy, your request is valid, you have simply exhausted a quota, and the Retry-After header tells you exactly when asking again will succeed. A 503 Service Unavailable is a confession: something on the server side — capacity, dependencies, a health check, a maintenance window — is not available right now, and the same Retry-After header carries far less certainty. RFC 6585 defined 429 in 2012 precisely because the 5xx series had no honest way to say "the problem is your pace, not our health." As of October 2026, the major API ecosystems have converged on this split: GitHub's REST API returns 429 for secondary rate limits with a Retry-After header measured in seconds, and the large model APIs — OpenAI, Anthropic, Google Gemini — all signal quota exhaustion with 429 while reserving 503 for genuine backend overload, per their current developer documentation.

What follows is the decision framework for emitting and interpreting each code: what RFC 9110 actually says about them, how to read the five signals that disambiguate a production response, which code your own rate limiter should emit for each of six implementation states, the client-side retry behaviour each code deserves, and the mistakes — Retry-After omissions, thundering herds behind a shared 503, SLO dashboards that count 429s as outages — that cause the most incident time. A comparison table separates 429 from 503 and from their nearest neighbours 502, 504 and 500, because half of all wrong fixes start as wrong status-code reads.

What RFC 9110 Actually Says About 429 and 503

The direct answer: 429 means the client has sent too many requests in a given time window and should slow down or stop, while 503 means the server is temporarily unable to handle the request due to overload or maintenance — the first is a client-error class 4xx, the second a server-error class 5xx, and that classification alone determines who is responsible for the condition.

The definitions are short but load-bearing. 429, defined in RFC 6585 and carried into modern HTTP semantics, states that the user has sent too many requests in a given amount of time, and the response SHOULD include a Retry-After header indicating how long to wait. 503, defined in RFC 9110 Section 15.6.4, states that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, and it too SHOULD include Retry-After. The word "temporary" is what distinguishes 503 from a hard failure — a 500 says the server itself is broken in a way it cannot describe.

Three properties of the definitions decide most real-world arguments:

• 429 is class 4xx, meaning the client can fix it by changing behaviour — slowing down, backing off, or purchasing more quota. The server is not admitting fault.
• 503 is class 5xx, meaning the server is admitting the problem is on its side, and the client's request was presumably fine.
• Both SHOULD carry Retry-After — a recommendation, not a mandate — which is why its absence is the single most common implementation defect, discussed in its own section below.

Because the class digit changes who owns the fix, the status code you emit is a statement about your architecture. A rate limiter that answers "you are too fast" with 503 tells every well-behaved client in the world that the service is sick — polluting monitoring, misdirecting retries, and inviting pager alerts for a condition that needed no human at all.

Five Signals That Disambiguate a Production Response

The direct answer: read, in order, the status class, the Retry-After value, the rate-limit headers, the response body's error code, and the correlation with your own request rate — these five signals separate a quota rejection from a genuine outage in under a minute, before you touch a dashboard.

In practice you rarely see a bare status code. Cloud front doors, API gateways and provider-side throttles add headers and bodies, and reading them in the right order is faster than any external check. The signals:

1. Status class first. 4xx points the finger at your request stream; 5xx points at the service. This single digit decides whether you throttle your own clients or open an incident.
2. Retry-After value. A 429 with Retry-After: 30 is a well-behaved quota — wait and proceed. A 503 with Retry-After: 3600 is a scheduled maintenance window. A 503 with no Retry-After at all is an unscheduled problem with unknown duration.
3. Rate-limit headers. x-ratelimit-remaining: 0 alongside a 429 confirms quota exhaustion; the same header with a positive value on a 429 points at a secondary limit — content-based, burst-based, or abuse-triggered — rather than your per-hour allocation.
4. Error body. Provider error codes are more specific than the status: a rate_limit_error type on a 429, an overloaded_error type on a 503, or a distinct error code for spend-limit exhaustion that merely shares the 429 status are different operational situations requiring different responses.
5. Your own rate. If your request volume has not changed and a 429 appears, suspect a shared-IP throttle, a token whose quota was consumed elsewhere, or a per-endpoint burst rule you had not noticed — not your aggregate pace.

The five-signal read works because each signal narrows the search space independently. In triage order: class tells you which side owns the problem, Retry-After tells you whether the sender expects you to come back, headers confirm whether a quota was the cause, the body names the exact limit, and your own telemetry rules out the possibility that someone else's traffic on your token is the real story.

Reading the Comparison: 429 vs 503 vs Their Neighbours

The direct answer: 429 means "your pace is the problem," 503 means "my capacity is the problem," 502 means "my gateway reached something invalid," 504 means "my gateway timed out waiting," and 500 means "my code failed" — and no two of these justify the same client response.

Half of all wrong fixes start as wrong status-code reads, so the table comes with a conclusion: if your client retries a 429 without honouring Retry-After, you are amplifying the exact condition that triggered it; if your client does not retry a 503 that carries a Retry-After, you are leaving availability on the table. Match the row to the code you actually received before writing any handler.

Two boundary cases deserve prose. A 429 for a spend-limit problem — quota exhausted because the billing cap was hit, not because requests were too fast — needs a payment action, not a backoff, which is why reading the error body matters more than the status digit. And a 503 emitted by a load balancer because its health checks are failing is a different incident from a 503 emitted by the application itself: the first means the fleet is unhealthy, the second means the app chose to shed load. The Server header or an identifying error field usually tells you which layer is speaking.

Six Implementation States and the Code Each One Deserves

The direct answer: a quota exceeded at the edge should return 429 with Retry-After, a dependency timeout under load should return 503 with Retry-After, a maintenance window should return 503 with an absolute-date Retry-After, and the other three states — burst rejection, queued overflow, health-check failure — each have exactly one correct code, and picking the wrong one converts a self-healing condition into a pager event.

A rate limiter is not one mechanism but six, and each state has a correct status code:

1. Token-bucket exhausted (too fast). The client burned its tokens before the refill. Emit 429 with Retry-After set to the next refill moment — seconds, not minutes.
2. Quota exhausted for the period (too many). The daily or hourly allocation is gone. Emit 429 with Retry-After set to the reset timestamp, and prefer an absolute date over a delta where the provider supports it.
3. Concurrency cap reached. All worker slots are busy with in-flight requests. This is a temporary capacity state, not a client fault — 503 with a short Retry-After is the honest answer, though well-tuned systems often emit 429 here when the cap exists to protect one noisy tenant.
4. Dependency overload. A database or downstream API is saturated and the service is shedding load to survive. Emit 503 with Retry-After, and let the load shedder decide the window — this is the classic 503.
5. Scheduled maintenance. Deliberately offline. Emit 503 with Retry-After as an absolute date-time so clients do not poll aggressively across the window.
6. Health-check failure. The balancer cannot reach healthy backends. The balancer emits 503 — and this is the state where the Retry-After is most often missing, because the balancer was not built to speak the application's retry contract.

The unifying principle: 429 when the client's behaviour is the cause and a known moment of relief exists; 503 when the server's capacity is the cause. The table that follows is the summary engineers tend to pin next to the rate-limiter configuration, with the conclusion stated up front: if your table row's "correct code" column disagrees with what your gateway currently emits, that disagreement is an incident waiting for a quiet afternoon.

Why Omitting Retry-After Is a Production Incident You Scheduled

The direct answer: a 429 or 503 without a Retry-After header forces every client to guess the wait, and guesses cluster at aggressive defaults — 1 second, often with no jitter — which synchronises retries into a thundering herd that can out-pressure the original spike the limiter was built to absorb.

RFC 6585 and RFC 9110 both use "SHOULD" for Retry-After, which in standards language means "ignore this only when you understand the full cost of doing so." The cost is concrete. A client that receives 429 without Retry-After picks a default — typically 1 second — and if hundreds of clients make the same guess in the same second, their synchronized retries land together, get rejected together, and retry again together. The herd does not disperse; it oscillates. Adding a single digit of random jitter to each client's wait is the cheapest known mitigation, but the better fix belongs to the server: emit the header, because the server is the only party that knows the true window.

The header supports two formats, and choosing correctly matters:

1. Delta-seconds — Retry-After: 30 — meaning "try again in 30 seconds." Right for token refills and load-shedding windows.
2. HTTP-date — Retry-After: Wed, 21 Oct 2026 07:28:00 GMT — meaning "the condition ends at this moment." Right for maintenance windows and quota resets, where an absolute moment is known.

One caution from field experience: delta-seconds values computed from a rate window can be wrong by up to one full window if the client's clock and the server's window boundary disagree. When your limiter knows the reset boundary — and it always does — the absolute date format is the more defensible emission.

Client-Side Backoff: Different Codes, Different Duty

The direct answer: on 429 you should back off for exactly Retry-After — honouring it is your side of the contract — while on 503 you should retry with capped exponential backoff and jitter, treating Retry-After as a ceiling rather than a schedule, because a 503's promise is less certain than a 429's.

The asymmetry comes from who owns the condition. A 429's Retry-After is a contract term: the limiter knows when your token bucket refills and is telling you the exact moment asking again will work. Waiting longer is waste, waiting less is a new violation. A 503's Retry-After is an estimate about someone else's recovery: capacity may return sooner, or later, and the client's duty is bounded patience, not obedience.

A correct retry policy for both codes, as converged practice in major API client libraries as of October 2026:

1. On 429: sleep for Retry-After (or its fallback), plus jitter between 0 and 1 second. Do not compute exponential backoff on top — the limiter already told you the answer.
2. On 503: exponential backoff starting at the Retry-After value or 1 second, doubling up to a cap of 30-60 seconds, with full jitter, for a maximum of 3-5 attempts.
3. On 429 for spend-limit conditions: stop retrying entirely — no backoff recovers a billing cap — and surface a payment-needed error to the operator.
4. Across all retries: use the same request idempotency key on every attempt, because a retry after a timeout may have been received and processed the first time.
5. When a retry budget — a shared counter of permitted retries per minute — hits zero, fail fast with a local error rather than queueing, so one degraded dependency cannot consume your whole worker pool.

The idempotency-key rule deserves emphasis in the AI-agent era: agents that retry AI API calls after timeouts without idempotency keys can duplicate side effects and double-spend quota, a failure pattern documented in production postmortems throughout 2026. The retry policy is not complete until the request it retries is safe to process twice.

The Thundering Herd Behind a Shared 503

The direct answer: when a load balancer emits a blanket 503 because one backend is unhealthy, every well-behaved client that honours Retry-After will retry simultaneously at the same moment, and the herd can hit harder than the original request spike — which is why the balancer's Retry-After should carry jitter baked into the value, not a constant every client will echo.

The scenario is common enough to have a name in postmortem culture. A fleet of 200 backends loses 10 to a bad deploy. The balancer, seeing capacity fall, begins shedding load with 503s. Each 503 carries Retry-After: 5. Ten thousand clients read "5", sleep exactly 5 seconds, and return as a single wave — arriving precisely when the balancer is still recovering. The wave is rejected again, sleeps another 5, and returns again in lockstep. Meanwhile the 190 healthy backends idle because the herd is synchronized against the shedding window rather than distributed across time.

Three mitigations, in order of effectiveness:

1. Server-side jitter: the balancer emits Retry-After values randomized within a band — 5 to 11 seconds — so the returning herd is spread across the band instead of its start.
2. Client-side full jitter: exponential backoff with full jitter (a uniform random wait between 0 and the exponential cap) decorrelates clients that were never given a reason to agree.
3. Retry budgets: a cap on the retry ratio — commonly 20 percent of live requests — enforced at the client or service-mesh layer, so retries cannot become the majority of traffic.

The same mathematics applies to your own API's clients, which is the practical reason to audit your 503 emissions: you cannot control every client's jitter discipline, but you can control whether your Retry-After values give them a reason to synchronize.

Monitoring: Counting 429s as Outages Is a Dashboard Lie

The direct answer: 429s are not errors — they are the rate limiter working — so your error-rate SLO should count 5xx only, track 429s as a quota-and-throttling metric with its own dashboard, and alert on the 429 rate crossing a client-experience threshold rather than on any 429 existing at all.

The most expensive category of status-code mistake is not technical but observability. A team that lumps 4xx and 5xx into one "error rate" metric will see a rate limiter doing its job — say, 2 percent of requests throttled during a traffic spike — as a service degradation, page an on-call engineer, and start investigating a healthy system while the real signal, whatever drove the traffic anomaly, goes unexamined. The fix is structural:

1. Split the error-rate SLO: 5xx counts against availability; 429 counts against a separate quota-utilization indicator.
2. Track the ratio of 429s with a Retry-After header to those without — a falling ratio means the limiter's contract with clients is degrading.
3. Alert on 429 rate per client, not in aggregate: one client at 60 percent throttled is an integration problem worth a phone call; ten thousand clients at 0.1 percent throttled is Tuesday.
4. Correlate 503 bursts with health-check failures and deploy timestamps — the two events that produce most unscheduled 503s — so the alert context arrives pre-loaded with the likely cause.

The 429-with-Retry-After ratio deserves a word of explanation: it is the single best leading indicator of how much retry traffic your limiter is converting into herd risk. A healthy limiter emits the header on every throttle; a gateway in front of it that strips headers — some do — silently converts your careful contract into blind client guessing, and the falling ratio is how you notice.

Why Gateways Strip Your Carefully Crafted Headers

The direct answer: API gateways, CDNs and sidecar proxies frequently rewrite or strip Retry-After and rate-limit headers from upstream responses — sometimes to enforce their own throttle above yours, sometimes as a misconfiguration — and a client seeing a 429 without Retry-After should suspect the middle layer before blaming the origin.

The layering problem is structural. Your request crosses your client's retry layer, possibly a service mesh, the provider's edge, the provider's gateway, and only then your application's own limiter. Each hop can emit its own throttle or rewrite the one it forwards. Three cases dominate production incidents:

• An edge CDN enforces its own per-IP burst limit — stricter than the application's — and answers 429 from the edge without ever consulting the origin. The client sees the application's status code vocabulary wearing someone else's policy.
• A gateway maps upstream errors to its own error catalogue for consistency, and in the mapping drops Retry-After, x-ratelimit-remaining, and the provider's specific error codes, leaving a 429 that says nothing about when or why.
• A sidecar or reverse proxy adds its own retry logic internally, receives the origin's 429, retries it against the origin automatically, and forwards the eventual success — meaning the client never learns its true pace exceeded the limit until the sidecar's own retry budget is exhausted and the failure surfaces as something else entirely.

The diagnostic is a header audit from two vantage points: send one request from inside the network — origin-adjacent — and one from outside, and diff the response headers. The headers present inside but absent outside were stripped by the middle layer, and the layer that stripped them is the one to reconfigure. Teams that run this audit annually report fewer "mystery 429" tickets than teams that debug from the client side alone, because the client side can only ever see the final, possibly rewritten, envelope.

Where This Leaves Your Rate Limiter

The direct answer: a rate limiter that emits 429 with Retry-After for quota states and 503 with Retry-After for capacity states — and never the reverse — is telling the truth, and truthful limiters produce self-healing client behaviour while untruthful ones convert every traffic spike into either a pager event or a thundering herd.

The six-state table and the five-signal triage sequence are the two artifacts worth carrying forward. For teams that want to rehearse both sides of the contract — a limiter emitting correct codes, and a client honouring them — the environment needs are modest: a small server to run nginx or an API gateway, a public address to test from outside, and enough root access to deliberately saturate a token bucket and watch the herd form and disperse. SurferCloud's ULightHost line fits this lab use case, with root access, dedicated IPv4, and entry configurations from $2.9 per month as of October 2026 per the current promotion page; the tiers and pricing details are on the ULightHost promotions page. A week of deliberate throttle-and-retry experiments on a machine you can break teaches more than a year of reading retry-policy documentation.

The status code is a statement about your architecture. Get the digit right, attach the header, add the jitter — and the two codes stop being a trivia question and start being the contract that keeps your clients well-behaved without a single human in the loop. That contract is worth rehearsing, and an inexpensive always-on instance is the cheapest rehearsal space there is.

Frequently Asked Questions

Is a 429 an error I should fix on my side or theirs?

Yours. The 4xx class digit means the client's behaviour caused the condition — too fast, too many, or a spend cap reached — and the fix is backoff, quota increase, or payment, respectively. Read the error body to distinguish the three.

Should I retry on a 503 or treat it as an outage?

Retry, with capped exponential backoff and jitter, for a maximum of 3-5 attempts. A 503 is by definition temporary. If Retry-After is present, treat it as a ceiling on your wait, not a schedule to obey exactly — the server's estimate of its own recovery is less certain than a quota window.

Why do I get a 429 with no Retry-After header?

Usually a middle layer stripped it. Audit response headers from inside and outside the network and diff them; headers present on the inside but missing outside were removed by a gateway, CDN, or sidecar, and that layer is the one to reconfigure. Retry-After is a SHOULD in the RFCs, so some origins also simply omit it.

What is the difference between 502 and 503 in a load balancer's logs?

A 502 means the balancer reached an upstream and the upstream's answer was invalid or the connection failed — the upstream is speaking, but wrongly. A 503 means the balancer is declining to forward at all — no healthy upstream, deliberate load shedding, or maintenance. 502 is an upstream incident; 503 is a capacity or availability decision.

Can I return 503 from my rate limiter to make clients slow down gently?

You can, but you are lying to them. A 503 tells clients your service is unhealthy, which pollutes their monitoring, misdirects their retries into outage playbooks, and invites pager alerts for what is actually their own request pace. Emit 429 with Retry-After instead — that is the code's entire reason to exist.

How do I stop my retries from synchronizing into a thundering herd?

Two layers: server-side, randomize Retry-After values within a band so returning clients spread across it; client-side, apply full jitter to backoff waits so independently written clients have no reason to agree on a return time. Add a retry budget — a cap on the retry ratio, commonly 20 percent — as the backstop.

Should my error-rate SLO include 429s?

No. Count 5xx against availability; track 429s as a separate quota-and-throttling metric. A rate limiter doing its job is not an outage, and teams that conflate the two page engineers to investigate healthy systems while the actual anomaly goes unexamined.

Do all the big AI APIs use 429 for rate limits?

As of October 2026, yes — OpenAI, Anthropic and Google Gemini all signal quota exhaustion with 429, though their error bodies differ (rate_limit_error types, RESOURCE_EXHAUSTED codes) and some share the 429 status with spend-limit conditions that need payment rather than patience. Read the body, not just the digit.