429 Too Many Requests
The user has sent too many requests in a given amount of time.
Usually happens because:
- ☑ Client script looping API requests
- ☑ Scraping bots crawling pages aggressively.
- ☑ IP addresses sharing requests exceeding
🔍 Quick Checklist:
Meaning
The HTTP 429 Too Many Requests client error status code indicates the user has sent too many requests in a given amount of time (rate limiting). It should include a Retry-After header indicating how long the client must wait.
Root Causes
- Client script looping API requests endlessly (accidental DDOS).
- Scraping bots crawling pages aggressively.
- IP addresses sharing requests exceeding firewall thresholds.
| Cause | Frequency |
|---|---|
| Client script looping API requests | ⭐⭐⭐⭐⭐ |
| Scraping bots crawling pages aggressively. | ⭐⭐⭐⭐ |
| IP addresses sharing requests exceeding | ⭐⭐⭐ |
Common Mistakes
- Failing to supply a 'Retry-After' header, causing clients to poll continuously instead of backing off.
- Misconfiguring rate limit rules on shared IP addresses (e.g. office NAT IPs), blocking entire companies.
How to Fix
Framework-Specific Examples
Enforcing rate limiting using express-rate-limit middleware.
const rateLimit = require('express-rate-limit');
const limiter = rateLimit({
windowMs: 60 * 1000, // 1 minute
max: 100, // limit each IP to 100 requests per windowMs
message: 'Too many requests, please try again later.',
statusCode: 429
});
app.use('/api/', limiter);Server Configuration Examples
Configuring Nginx limit_req zone parameters.
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
server {
location /search/ {
limit_req zone=one burst=5 nodelay;
}
}Prevention
- Setup rate limit alerts inside server monitor dashboards.
- Implement exponential backoff algorithms inside API clients.
Frequently Asked Questions (FAQ)
Q: What is rate limiting?
Rate limiting is a server strategy to limit the number of requests a client (identified by IP, API key, or user token) can make within a specific timeframe, protecting servers from overload and DDoS.
Q: What header guides client backoff periods on 429?
The server should return the 'Retry-After' header, which specifies the number of seconds (e.g. `Retry-After: 60`) or a GMT date indicating when the client can retry.
Q: Is 429 Too Many Requests cacheable?
No. The 429 status code is never cached.
Q: How do clients handle 429 errors?
Clients should intercept 429 responses, read the Retry-After header, pause all outgoing API requests, and resume after the backoff timer expires.