Common causes
- A script, cron job or integration sends requests in a tight loop
- An API's per-minute or per-day quota is used up
- Nginx limit_req or a CDN rate-limiting rule is set too strict
- Many users share one IP (office NAT, proxy) and hit an IP-based limit
- Bots or brute-force attempts on login or xmlrpc.php trigger the limit
- Retries without backoff multiply the request count
How to fix it
- Read the Retry-After header. Many servers send Retry-After with a number of seconds or a date. Wait that long before trying again.
- Add exponential backoff. In your client code, retry 429 responses after 1s, 2s, 4s and so on, with a cap. Never retry immediately in a loop.
- Reduce request volume. Cache API responses, batch requests where the API allows it, and remove duplicate calls. Check your API dashboard for quota usage.
- Tune Nginx limit_req on your server. If your own site returns 429, look for limit_req_zone and limit_req in the Nginx config. Add a burst value, for example limit_req zone=one burst=20 nodelay;, so normal page loads with many assets pass.
- Check CDN and security plugin rules. Cloudflare, Wordfence and similar tools have rate limits. Review their logs to see which rule fired and whitelist trusted IPs like your monitoring service.
Nginx rate limit that allows short bursts
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
limit_req_status 429;
server {
location / {
limit_req zone=one burst=20 nodelay;
}
}
}How to stop it happening again
- Respect API quotas and cache responses
- Always use backoff with jitter when retrying
- Apply strict limits only to sensitive paths like login
- Monitor 429 counts in your logs