The client is sending requests too fast.
When to use it
Rate limiting. Include a Retry-After header.
Common causes and fixes
You hit a rate limit. Read the Retry-After header, in seconds or as an HTTP date, and any RateLimit or X-RateLimit-Remaining headers, then back off with exponential delays and jitter instead of retrying at once. Common sources: API quotas per key or IP, Cloudflare rate limiting rules, login throttling, and nginx limit_req, which returns 503 unless you set limit_req_status 429.
Many users behind one NAT or corporate proxy can trip an IP limit together. If you run the limiter behind a load balancer, key it on the real client IP from X-Forwarded-For, or every user shares the balancer’s address and quota. On the client side, batch requests, cache responses, and add random delay to scheduled jobs so they don’t all fire at the same second.
Client error (4xx)
4xx codes are client errors: the request itself is wrong, unauthorised or points at something that isn’t there. Retrying the same request won’t help.
What it looks like
HTTP/1.1 429 Too Many RequestsHow to send it
| Node.js / Express | res.status(429).end() |
|---|---|
| Python / Flask | return '', 429 |
| nginx | return 429; |
How to check it
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/