A 429 Too Many Requests error means the server has received more requests from you, your app or your site than it allows in a given window of time, and it is refusing more for now. It is a temporary block, not a broken site. Wait a bit, slow down, and if you run the site, find out what is generating the flood.
This guide covers both sides: visitors who just want the page to load, and site owners (especially on WordPress) who need to find the plugin, bot or script behind the error.
TL;DR
- A 429 is rate limiting: the client sent too many requests in a given amount of time.
- As a visitor, wait, then reload once. Do not hammer refresh. Check for a Retry-After value if you are calling an API.
- On WordPress, the usual culprits are a plugin or theme making runaway requests, a bot hitting login or XML-RPC, or a security rule that is too strict.
- To isolate the cause, disable plugins, switch themes, read your access logs, then add caching and bot blocking so it does not return.
- A 429 is different from a 503: 429 is aimed at one client, 503 means the server itself cannot cope.
Table of Contents
- What a 429 error actually means
- What to do if you are just a visitor
- How long does a 429 last?
- Why a 429 appears on your website
- How to fix a 429 error on WordPress
- Perspective: what we see in practice
- How to prevent 429 errors from coming back
- For developers: handling 429 in code
- 429 vs 503: what is the difference?
- When the fix is more resources
- FAQ
- Sources
What a 429 error actually means
HTTP 429 is a client error status code. MDN describes it as the response a server sends when a client has sent too many requests in a given period. The limit can apply across the whole server, to one resource, or to an IP address, a user or an authenticated application.
The status code was standardized in RFC 6585 in 2012. It lets a server say "you are over your quota" without pretending the site is down. The response may include a Retry-After header that tells you when to try again.
That makes a 429 less an error in the traditional sense and more a safeguard. Websites and services use rate limits to manage traffic spikes or stop abuse by temporarily blocking excessive requests. The server is protecting itself, and often protecting you.
You may see the same error worded differently:
- 429 Too Many Requests
- Error 429
- Too many requests, please try again later
- Rate limit exceeded
- HTTP 429 Too Many Requests (often with a server or CDN logo)
They all describe the same condition.
What to do if you are just a visitor
If you are trying to load a page and hit a 429, you rarely need anything technical.
- Stop reloading. Every refresh counts as another request and can extend the block.
- Wait a few minutes. Most limits reset within a minute to an hour. If the page shows a countdown or a Retry-After time, follow it.
- Close extra tabs and pause extensions. Auto-refresh tools, scrapers, download managers and some browser extensions fire many requests quietly.
- Check your network. If you share an IP address with many people (an office, school, VPN or mobile carrier), the limit may be hit by the group, not by you. Try a different network, or turn off the VPN.
- Log out and back in if the error appears only after login. Some sites count requests per account.
- Contact the site owner if the error persists for hours. The block may be a rule that needs adjusting.
If the message appeared after you requested a verification code several times, stop requesting codes for a while. Many services lock that action for hours after a few attempts.
How long does a 429 last?
It depends on the server's rules. The server may include a Retry-After header giving either a number of seconds or a specific date. MDN's example uses a value of 3600, which means requests will be allowed again after 3,600 seconds, or 60 minutes.
Without that header, there is no universal answer. Common patterns are:
| Situation | Typical recovery |
|---|---|
| Per-minute API quota | Resets at the end of the window; wait for it |
| Login or verification limits | Can last from minutes to hours |
| Security rule or firewall block | Until the rule expires or an admin clears it |
| Misconfigured plugin looping on itself | Does not clear until the loop is fixed |
The last row matters for site owners: if the cause is on your own site, waiting alone will not help.
Why a 429 appears on your website
Per the RFC, servers may limit requests per resource or across the whole server, and may identify users by credentials or a stateful cookie. In practice, on a site you run, the reasons fall into a few groups.
Bots and scrapers
Login pages, search, XML-RPC and comment forms attract automated traffic. If your host or a security layer rate-limits aggressively, real visitors can get caught in the same net. Spam on forms is part of the same story: stopping form spam without blocking real customers is about the balance between protecting a site and letting people through.
A plugin or theme making too many calls
On WordPress, the most common internal cause is a plugin that makes unthrottled API requests or stacks retries when one fails, as HubSpot's guide notes in its explanation of 429 errors. Think of backup tools, SEO crawlers, security scanners, chat widgets and anything that polls an external service from the admin.
A heartbeat or AJAX loop
The WordPress dashboard sends background requests while you edit. If a plugin or a caching layer misbehaves, those requests can pile up and trigger a block. One WordPress support thread describes a site where internal AJAX calls returned 429 and removing a .htaccess file inside wp-admin resolved it. That is one site's experience, not a universal fix, but it shows the error can come from your own rules.
Third-party limits
The 429 may not come from your server at all. When your site calls another service (a payments API, maps, email, social feeds), that service can answer your server with a 429. For example, Cloudflare's own API allows 1,200 requests per five minutes per user, counted across dashboard, API key and API token requests combined. Every provider has its own quota, so check the documentation of the service in your error log.
Traffic spikes and an underpowered plan
A viral post, a sale or a crawl can push a small plan past its limits. Hosts protect shared servers with per-account limits on concurrent connections and processes. If your site is slow before the 429 shows up, resources are probably the root problem. Our walkthrough on why a WordPress site is slow on shared hosting covers the checks to run first.
How to fix a 429 error on WordPress
Work from the cheapest, safest check to the most invasive. Take a backup before changing anything.
Step 1: Find out who is sending the requests
Before you disable anything, look at the data. Open your access logs in your hosting control panel and look for:
- One IP address or user agent with hundreds of hits in a short time
- Repeated hits on /wp-login.php, /xmlrpc.php or /wp-admin/admin-ajax.php
- A single URL requested over and over
If the traffic is one or two hostile addresses, you have a bot problem. If it is spread across your own pages or comes from your server's own IP, you have a plugin or loop problem.
Step 2: Disable plugins to find the culprit
This is the standard approach. Per Elegant Themes' troubleshooting guide, deactivate all plugins, then reactivate them one at a time and test after each to isolate the one causing the error.
If you cannot reach wp-admin, use FTP or your host's file manager and rename the wp-content/plugins folder (for example to plugins-off). WordPress will treat every plugin as inactive. Then restore the folder name and reactivate plugins individually from the dashboard.
Plugins worth suspecting first:
- Security and firewall plugins with login-attempt limits
- Backup and migration plugins running scheduled jobs
- SEO and link-checker plugins that crawl your own site
- Any plugin that connects to an outside API
Step 3: Test your theme
If plugins are clear, test the theme. When the dashboard is unavailable, the same guide suggests renaming your active theme's folder under wp-content/themes. WordPress should fall back to a default theme, which tells you whether the theme is behind the 429. Rename it back afterward.
Step 4: Review your .htaccess and server rules
A rewrite or rate-limit rule you or a plugin added can return 429 for legitimate requests. Rename .htaccess temporarily, then load the site. WordPress can regenerate the default by saving Settings > Permalinks. If the error disappears, add your custom rules back one at a time. Be careful with this on sites where the file holds security or caching directives, and keep a copy.
Step 5: Check your CDN and firewall
If a CDN or web application firewall sits in front of your site, it may be the one issuing the 429. Look at its rate-limiting rules and event log. Allow your own office IP, trusted monitoring services and search engine crawlers, and keep strict limits on login and XML-RPC.
Step 6: Ask your host
If nothing above explains it, contact support with a timestamp, the URL and the IP you saw. A host can see limits that you cannot from inside WordPress, such as per-account connection caps or server-level protections.
Perspective: what we see in practice
We run WordPress sites on LiteSpeed servers, and our engineers in the EU and US see the same pattern over and over. When a site owner reports a 429, the instinct is to raise limits or turn protection off. That is usually the wrong move.
The limit is rarely the problem. The traffic is. A login page hit by a bot network, a plugin polling an API every few seconds, or an admin screen left open in six tabs will generate more requests than any small site should need. Raising the ceiling just lets the waste continue and slows the site for real visitors.
Our advice is to fix in this order. First, identify the source from the logs. Second, cut the waste: caching, fewer plugins that call out, scheduled jobs moved off peak hours. Third, block what should never reach WordPress at the edge, before PHP runs. Only then, if real traffic outgrows the plan, move up. Our guides on protecting the WordPress login with edge blocking and on blocking bad bots without locking out users follow exactly this approach.
One more point: a rate limit that never blocks anyone is not protecting anything, and one that blocks customers is costing you sales. Test your rules while logged out, from a phone on cellular data, and with a checkout or contact form.
— Ihor
How to prevent 429 errors from coming back
Cache what does not change
Every request served from cache is a request PHP and the database never see. Page caching, object caching and a CDN for static files reduce the load that triggers server-side limits. Server-level caching generally outperforms a stack of plugins doing the same job.
Cut background polling
Audit plugins that call external services. Lengthen refresh intervals, disable features you do not use, and avoid plugins that crawl your own site on a schedule during business hours.
Block abuse early
Rate-limit login, XML-RPC and search by IP, and block known bad user agents at the edge or server. The aim is to turn away automated traffic cheaply, without waking WordPress. Make sure the rules identify clients properly: servers decide who is who by IP address, session cookie or credentials, and an overly broad rule on a shared IP can catch innocent users. For a technical look at how clients are told apart, see this piece on how APIs identify clients and apply limits.
Keep your site fast and healthy
Slow pages make visitors and scripts retry, which multiplies requests. Fixing a slow WordPress admin dashboard or running through six quick wins for a slow site removes a hidden source of repeat calls.
Get permissions and ownership right
Broken file permissions can make plugins fail and retry in loops. Setting everything to 777 does not help; see why in our guide to WordPress file permissions and ownership.
Size the hosting to the traffic
If logs show legitimate visitors being limited, your plan is too small for the load. Moving from shared hosting to a WordPress-optimized plan or a VPS gives you more CPU, memory and concurrent processes. More on that below.
For developers: handling 429 in code
If your script or app receives a 429 from an API, retrying immediately makes things worse. A sound client does this:
- Read Retry-After. If the response includes it, wait that many seconds, or until that date, before the next call.
- Use exponential backoff with jitter when there is no header: wait 1 second, then 2, then 4, with a little randomness so many clients do not retry in sync.
- Set a retry ceiling. Give up and log after a handful of attempts rather than looping forever.
- Reduce volume at the source. Batch requests, cache responses, and use webhooks instead of polling where the API offers them.
- Track your own usage. Count requests per window and throttle yourself before the server does.
Retry-After is not exclusive to 429. Servers can also send it with 503, so the same retry logic can cover both.
Note that 429 responses must not be stored by a cache. If you see a 429 served to many users after a block has lifted, check that your CDN or proxy is not caching an error page.
429 vs 503: what is the difference?
Both are temporary, and both can carry Retry-After, but they point at different problems.
| 429 Too Many Requests | 503 Service Unavailable | |
|---|---|---|
| Who is at fault | The client is sending too much | The server is not ready to handle requests |
| Scope | One user, IP, key or app | Usually everyone |
| Typical cause | Rate limit, bot rule, quota | Overload, maintenance, crashed process |
| Right fix | Slow down, fix the sender | Fix or scale the server, or wait |
MDN states that 503 means the server is not ready to handle the request, and that when specific clients are restricted by rate limiting, 429 is the appropriate response. If your whole site shows 503 while you are the only one seeing a 429, you are looking at two different problems.
When the fix is more resources
Sometimes there is no rogue plugin. A growing store, a busy membership site or a site with frequent API calls simply needs more capacity than a starter plan provides.
At inSave Hosting, WordPress hosting plans (WP Start, WP Growth, WP Pro and WP Agency) are built on LiteSpeed with LSCache, so most page views are served from cache and never reach PHP. Every plan includes free migration, daily backups and a 30-day money-back guarantee. If you outgrow shared resources, our VPS hosting gives you dedicated CPU and memory with room to set your own rate-limit rules. Agencies running many client sites can look at reseller hosting. Not sure which fits? Our engineers can read your logs and tell you whether you need a plan change or just a configuration fix.
FAQ
Is a 429 error my fault or the website's?
It depends on where the traffic comes from. The server is telling the client it sent too many requests, but the client might be a bot on a shared network, a plugin on your own site, or an app you wrote. Visitors can usually fix it by waiting. Site owners should check logs to find the source.
How long should I wait after a 429?
Follow the Retry-After header if there is one, since it gives the delay in seconds or a date. If there is none, wait a few minutes before one reload, and for API calls use increasing delays between retries. If the error lasts for hours, the block may be a security rule that needs clearing.
Does a 429 hurt my SEO?
A short-lived 429 for visitors is not a concern, but if search engine crawlers regularly receive it, they may crawl your site less. Make sure your rate limits and firewall rules allow legitimate crawlers, and fix the load problem behind the limit.
How do I fix too many requests on WordPress if I cannot log in?
Use FTP or your host's file manager. Rename the wp-content/plugins folder to deactivate all plugins, then try logging in. If that fails, rename your active theme folder so WordPress falls back to a default one. Restore the names and reactivate items one by one to find the cause.
Is 429 the same as rate limit exceeded?
Yes. "Rate limit exceeded" is the message many APIs, plugins and services show with a 429 status code. The cause and the fixes are the same: reduce request frequency, cache results, and respect the wait time the server gives you.
Sources
- 429 Too Many Requests, MDN
- RFC 6585, Additional HTTP Status Codes
- Retry-After header, MDN
- 503 Service Unavailable, MDN
- Error 429, Cloudflare Support docs
- What does HTTP error 429 mean, HubSpot
- What Is the HTTP 429 Error and How to Fix It, Elegant Themes
- LiteSpeed internal AJAX calls 429, WordPress.org support