429 - Too Many Requests
HTTP 429 Too Many Requests means the client sent too many requests in a given amount of time.
Last reviewed: February 12, 2026|Editorial standard: source-backed technical guidance
What Does Too Many Requests Mean?
Traffic exceeded an enforced rate window, so requests are being throttled and user-visible latency/errors will continue until request pacing is reduced.
Common Causes
- -Request rate exceeds configured per-client or per-user limits.
- -Retry storms amplify traffic during partial outages.
- -Parallel workers create burst load spikes.
How to Fix Too Many Requests
- 1Honor Retry-After guidance and throttle request bursts immediately.
- 2Apply bounded exponential backoff with jitter and strict retry budgets.
- 3Reduce concurrency and smooth traffic spikes to stay within rate-limit windows.
Step-by-Step Diagnosis for Too Many Requests
- 1Capture throttling signals by dimension (token, IP, tenant, API key, route) at the failure window.
- 2Inspect `Retry-After` and provider-specific rate-limit headers to identify window and reset behavior.
- 3Trace retry logic for synchronized retries, missing jitter, and uncontrolled worker fan-out.
- 4Retest with capped concurrency, client-side rate limiting, and jittered backoff budgets.
Rate-Limit Dimension and Window Analysis
- -Identify which quota bucket is saturated (example: per-token limit fine, but shared per-IP limit exhausted behind NAT).
- -Correlate burst patterns with cron jobs/release events (example: top-of-minute batch starts 200 workers simultaneously).
Retry and Traffic Shaping Controls
- -Audit retry fan-out and jitter quality (example: fixed 1s retries create synchronized retry storm).
- -Validate local token-bucket or leaky-bucket controls in clients (example: mobile SDK missing limiter on offline replay).
Implementation Examples
curl -i -X GET https://api.example.com/v1/reports/heavy
# Response:
# HTTP/1.1 429 Too Many Requests
# {"error":"Too Many Requests","code":"429"}const response = await fetch('https://api.example.com/v1/reports/heavy', {
method: 'GET',
headers: { 'Accept': 'application/json' }
});
if (response.status === 429) {
console.error('Handle 429 Too Many Requests');
}import requests
response = requests.get(
'https://api.example.com/v1/reports/heavy',
headers={'Accept': 'application/json'}
)
if response.status_code == 429:
print('Handle 429 Too Many Requests')How to Verify the Fix
- -Run controlled load tests and confirm 429 no longer appears under target traffic profiles.
- -Validate Retry-After handling and jittered backoff behavior in all clients.
- -Monitor request-rate and throttle metrics to confirm stable headroom.
How to Prevent Recurrence
- -Enforce shared retry standards with jitter, budgets, and idempotency requirements.
- -Add rate-limit and quota alerts before traffic reaches enforcement thresholds.
- -Smooth burst traffic with queues, batching, and adaptive concurrency controls.
Pro Tip
- -implement distributed client-side pacing keyed by the same principal dimension as the server limiter to prevent cross-worker burst amplification.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
AWS ThrottlingException vs GCP RESOURCE_EXHAUSTED
Compare AWS ThrottlingException and GCP RESOURCE_EXHAUSTED to separate rate limiting from quota/resource exhaustion and choose the remediation path.
Playbook
Rate Limit Recovery Playbook (429 / ThrottlingException / RESOURCE_EXHAUSTED)
Use this playbook to separate transient throttling from hard quota exhaustion and apply retry, traffic-shaping, and quota-capacity fixes safely.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.