429 Too Many Requests
4xx client error
The client sent too many requests in a given amount of time — it's being rate limited.
429 is rate limiting. The server — or an API gateway or CDN in front of it — counted your requests, and you went over the allowance. A well-behaved server includes Retry-After (seconds to wait, or a date), often alongside headers that show the quota. A well-behaved client waits that long before trying again instead of hammering the server.
| Class | 4xx Client Error |
|---|---|
| Retry? | With backoff (idempotent requests only) |
| Cacheable by default | No — only with explicit Cache-Control |
| Response body | Allowed |
| Defined in | RFC 6585 §4 — 429 Too Many Requests |
HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json
Content-Length: 29
{"error":"Too Many Requests"}Common causes
- Exceeding an API's per-second, per-minute or daily quota.
- Many parallel requests from one IP address or API key.
- Retry loops without backoff, which turn one failure into hundreds of requests.
- Shared IPs — offices, CI runners, cloud NAT — pooling everyone's traffic into one limit.
How to fix it
- Honour
Retry-After. Without it, back off exponentially with jitter: about 1 s, 2 s, 4 s, plus a random offset. - Cache responses and batch requests to cut volume.
- Smooth bursts out with a queue.
- If you legitimately need more, ask for a higher quota or a dedicated key.
Useful here: Retries, backoff and Retry-After
Send a 429 from your server
res.set("Retry-After", "60");
res.status(429).json({ error: "Too Many Requests" });return Response.json({ error: "Too Many Requests" }, { status: 429, headers: { "Retry-After": "60" } });return {"error": "Too Many Requests"}, 429, {"Retry-After": "60"}w.Header().Set("Retry-After", "60")
http.Error(w, "Too Many Requests", http.StatusTooManyRequests)add_header Retry-After "60" always; return 429;
Check what a URL returns
Print just the status line from the command line, or check a whole list of URLs at once, with their response headers, in the HTTP Status Checker.
curl -sI https://example.com/your-path | head -n 1
Frequently asked questions
How long should I wait after a 429?
Exactly as long as Retry-After says. Without it, use exponential backoff with jitter and cap the number of retries.
429 vs 503?
429 is about you: this client exceeded its limit. 503 is about the server: it's overloaded or down for everyone. Both may carry Retry-After.
How do I rate limit my own API?
In nginx, use limit_req_zone and limit_req; in Express, middleware such as express-rate-limit. Respond with 429 and Retry-After so clients can recover.