429 Too Many Requests means the server is refusing requests because too many were sent in a short period. The site may still be online, but it is rate-limiting you, your browser, a bot, a plugin, or an application.
This is not a total outage. In most cases the real problem is request volume, burst traffic, bad automation, login abuse, API overuse, or rate-limit rules that are too strict.
Quick Fix
- Wait a minute and try again.
- Check whether the response includes a
Retry-Afterheader. - Reload less aggressively. Do not spam refresh.
- Log out and back in if the issue is session-based.
- Clear cookies for the site if only one site fails.
- Disable VPN, proxy, scraper, or auto-refresh extensions.
- Try another network if your current IP may be limited.
- If you own the site, check logs, firewall rules, CDN rules, and rate limits.
- If you run WordPress, check login abuse and suspicious plugins.
- If you run an API client, add throttling, backoff, and a request queue.
What Is 429 Too Many Requests?
429 Too Many Requests is an HTTP status code. It means the server received too many requests from the same client, token, user, IP, or session within a defined window.
The server is usually doing this on purpose. A 429 is a control mechanism, not just a crash symptom. Sites use it to protect pages from abuse, APIs from overuse, login forms from brute force, and backends from overload.
The response may include a Retry-After header. That tells the client when to try again. If it is present, respect it instead of retrying harder.
You may see 429 in a browser, in Postman or curl, on WordPress login, in a mobile app, or in a cron job.
Why 429 Too Many Requests Happens
1. Too Many Requests in a Short Time
The client exceeded the allowed rate. Examples: refreshing too often, an API loop, a broken poll every second, many tabs hitting the same endpoint, or many users sharing one NAT IP.
2. Rate Limits Are Too Aggressive
Traffic can be normal while the limit is too low. This happens with a strict firewall rule, an untested CDN limit, a small API quota, a harsh login threshold, or a hidden shared-hosting cap.
3. A Bot, Plugin, or Script Is Hammering the Site
Common offenders: a WordPress security plugin, a broken cron, an uptime monitor with a bad interval, a search indexer, an inventory sync tool, or a mobile app that retries too fast.
4. Login Protection or WAF Rules Are Triggering
Many sites rate-limit /wp-login.php, /xmlrpc.php, search, checkout, REST API, and admin pages. The site is not necessarily broken. It is blocking a pattern it treats as risky.
5. Too Many Concurrent Requests
Some systems also limit bursts. A scraper with many parallel connections, a frontend firing duplicates, or workers retrying instantly can trip the limit even if the per-minute count looks fine.
6. Shared IP Reputation or NAT Collisions
If many users share one public IP, limits can trigger even when your own behavior looks normal. This is common on corporate networks, schools, public Wi-Fi, mobile carriers, and cheap proxies.
7. A CDN, Proxy, or Upstream Is Returning the 429
The origin is not always the source. The 429 may come from Cloudflare, NGINX, a WAF, an API gateway, the app, or an upstream API your app depends on. The fix depends on which layer sent it.
How to Fix 429 Too Many Requests Step by Step
1. Wait and Retry Properly
If you are browsing, stop sending more requests. Wait 30 seconds to a few minutes. If the response shows Retry-After, follow it.
2. Check Whether the Problem Affects One Site or Many
- One site → that site or your session on it is the problem.
- Many sites → a local tool or shared IP is more likely.
- Only one app fails → check that client first.
3. Disable VPN, Proxy, Scraper, or Browser Extensions
Temporarily disable VPNs, proxies, scraping extensions, SEO tools, and auto-refresh add-ons. If the site starts working, one of those tools is the trigger.
4. Clear Cookies and Cache for the Affected Site
Open a private window and try again. If it works, clear cookies for that domain and log in again. This helps when the limit is tied to session state.
5. Try Another Network or IP
Test on mobile data or another Wi-Fi network. If the error disappears, the limit was probably tied to the original IP or IP range.
6. If You Use an API, Respect Retry-After and Add Backoff
The client should read Retry-After, pause before retrying, use exponential backoff, avoid instant loops, and queue or batch requests. Bad retry logic turns a small 429 into a permanent one.
7. Reduce Request Frequency and Burst Size
Space requests evenly, add jitter, lower worker concurrency, debounce frontend calls, and drop duplicate requests. This matters for API integrations and JavaScript-heavy apps.
8. Check WordPress Plugins, Themes, and Login Traffic
Check security plugins, caching plugins, theme AJAX loops, REST API calls, heartbeat, brute force on wp-login.php, and XML-RPC abuse. A plugin loop or an attack often sits behind repeated 429 responses.
9. Review Server, WAF, CDN, and Application Logs
Look for which endpoint returns 429, which IPs trigger it, whether it is users or bots, and whether the response came from the app, NGINX, CDN, or firewall.
10. Check NGINX Rate Limit Rules
Inspect limit_req rules. Common problems: rate set too low, wrong key, a global rule on sensitive paths, no burst allowance, or login sharing the same limit as static pages. A login page, an API route, and an image request do not need identical limits.
11. Check Cloudflare Rate Limiting and Security Rules
Review rate limiting, WAF, bot rules, and rules on login or API routes. The page can look like a site error while the edge layer is the real source.
12. Look for Infinite Loops and Duplicate Requests
Typical causes: frontend polling, React or Vue effects firing repeatedly, sync jobs retrying without delay, broken webhooks, and a cron calling the same endpoint constantly. One bug can flood an endpoint for everyone else.
13. Raise Limits Only After You Understand the Traffic
Raise limits only if the traffic is legitimate, the endpoint needs higher throughput, the server can handle it, and the cause is not a loop, bot, or attack. Otherwise you only hide the problem.
Advanced Troubleshooting
Identify Which Layer Returns the 429
The response may come from application code, NGINX or Apache, a reverse proxy, Cloudflare, an API gateway, or an upstream API. Check headers, signatures, and logs. If the app never saw the request, changing app code will not help.
Check Retry Logic in Code
Look for code that retries instantly, retries in parallel, ignores Retry-After, duplicates requests on timeout, or retries on both the client and the server.
Review Per-IP vs Per-User vs Per-Token Limits
Per-IP limits punish shared office networks. Per-user limits punish people with many tabs. Per-token limits punish integrations that share one token across workers. The wrong key makes normal traffic look abusive.
Use Logging Mode Before Tightening Rules
If the tool supports a non-blocking or logging-only mode, use it before enforcing new rules. That shows who would be blocked and what a safe threshold looks like.
Check Background Jobs and Cron Schedules
Review cron frequency, webhook retries, queue workers, sync intervals, and uptime monitors. A five-second cron hitting a slow endpoint can look like abuse.
Prevention Tips
- Respect
Retry-Afterin all API clients. - Use exponential backoff, not instant retries.
- Add jitter to automated retries.
- Rate-limit login and search separately from normal pages.
- Monitor logs for noisy endpoints and 429 spikes.
- Cache identical requests where possible.
- Debounce frontend calls and remove duplicates.
- Do not share one API token across too many workers.
- Test new rate-limit rules in logging mode first.
When to Contact Support
Contact the site owner if you are a normal visitor, only that site shows 429, and waiting does not clear it.
Contact hosting if your own site returns 429 unexpectedly, you cannot tell which layer generates it, or legitimate traffic is being limited.
Contact the API vendor if usage is within documented limits, limits changed without notice, or you need a higher production quota.
FAQ
What does 429 Too Many Requests mean?
The server is rate-limiting the client because too many requests arrived in a defined period. The server is usually still online.
Is 429 my fault or the website’s fault?
It can be either. The client may really be sending too much, or the site, CDN, firewall, or API gateway may be counting traffic too strictly.
How long does a 429 error last?
It depends on the window. Some clear in seconds. Others last minutes. If the response includes Retry-After, use that value.
How do I fix 429 Too Many Requests in WordPress?
Check security plugins, login protection, XML-RPC, REST API traffic, theme or plugin loops, Cloudflare rules, and server logs.
How do I fix 429 Too Many Requests in an API client?
Reduce frequency, limit concurrency, respect Retry-After, add exponential backoff, and avoid retry loops.
Final Thoughts
429 Too Many Requests is usually not a mystery and not a total outage. It is a rate-limit response. Find who is sending too many requests, which layer enforces the limit, and whether the traffic is abusive, accidental, or legitimate.
Start with scope: one site or many, one endpoint or all. Then identify the layer returning the 429, inspect logs, fix retry behavior, and tune limits only after you understand the pattern.