A 429 status code means the server is refusing your request because you have sent too many requests in a given time window. It is a rate limit. The server is not broken, not overloaded, and not blocking you permanently – it is telling you to slow down.
Rate limiting exists because servers have finite resources. Every request consumes CPU, memory, bandwidth, and often database connections. Without limits, a single client making thousands of requests per minute could degrade the service for everyone else. The 429 response is how servers enforce these boundaries in a way that tells the client exactly what happened and what to do about it.
This guide covers why 429 errors happen, how to read the response headers to understand the rate limit, what to do when you are being rate-limited as a client, and how to configure rate limiting properly as a server administrator.
What a 429 response looks like#
A 429 response includes the status code and usually a
Retry-After
header that tells you when to try again:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: text/html
<html><body><h1>Too Many Requests</h1>
<p>You have sent too many requests in a given amount of time.</p>
</body></html>
The
Retry-After
header value is in seconds (60 means wait one minute) or an HTTP date. Not all servers include it, but well-configured ones do. If the header is present, respect it – sending more requests before the window resets just extends the block.
Some APIs return additional rate limit headers:
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1712577600
These tell you the total limit (100 requests), how many you have left (0), and when the window resets (as a Unix timestamp). These headers are not standardized but are widely used by REST APIs.
429 vs 403 vs 503#
These errors can look similar from the client side but have different meanings:
429 Too Many Requests – you exceeded a rate limit. Temporary. Wait and try again. The server is healthy and serving other clients normally.
403 Forbidden – the server understood your request but refuses to fulfill it. This is typically an authorization issue, not a rate limit. You might be blocked by IP, missing authentication, or accessing a restricted resource. A 403 does not usually resolve by waiting.
503 Service Unavailable – the server cannot handle any requests right now, not just yours. The server is overloaded, under maintenance, or a backend service is down. A 503 affects everyone, not just the client that hit a rate limit.
If you are seeing a 403 when you expect a 429, the server may be using the wrong status code (common with older security plugins), or your IP has been permanently blocked rather than rate-limited.
Why you are getting a 429#
As a website visitor
The most common scenario: you are trying to log in, submit a form, or browse a site and get a 429 error. This usually means:
- You submitted a login form too many times with wrong credentials. Server-side tools like fail2ban or WordPress security plugins track failed attempts and block further requests after a threshold.
- A security plugin is rate-limiting your IP because your browsing pattern resembles automated traffic – too many page loads in a short period, rapid-fire form submissions, or accessing URLs in a pattern that matches known bot behavior.
- You share an IP address with other users (corporate network, VPN, public wifi) and the combined traffic from all users exceeded the per-IP limit.
What to do: Wait. Most rate limits reset within 1 to 15 minutes. If you see a
Retry-After
header, wait that long. If the limit persists, you may be behind a shared IP that is getting rate-limited because of other users’ traffic. Try switching to a different network or disabling your VPN.
If you are a site administrator getting locked out of your own WordPress site by rate limiting, the WordPress 429 too many requests guide covers how to identify which layer is generating the block and how to whitelist your IP.
As an API consumer
You are making HTTP requests to a third-party API (Stripe, Google, OpenAI, Twitter, GitHub) and receiving 429 responses. This is the API telling you that you have exceeded your allocated request quota.
Most APIs publish their rate limits in their documentation:
- Stripe: 100 read requests/sec, 100 write requests/sec
- GitHub API: 5,000 requests/hour (authenticated), 60 requests/hour (unauthenticated)
- OpenAI: varies by model and plan tier
- Google Maps: varies by API and billing plan
What to do:
Implement exponential back-off. When you receive a 429, do not immediately retry. Wait, then retry with increasing delays:
First retry: wait 1 second
Second retry: wait 2 seconds
Third retry: wait 4 seconds
Fourth retry: wait 8 seconds
Add jitter (a small random delay) to prevent multiple clients from retrying in sync and creating a thundering herd.
Cache responses. If you are making the same API call repeatedly, cache the response. A DNS lookup result does not change every second. A product price does not change every minute. Cache what you can, and only make API calls when the cached data expires.
Batch requests. Some APIs let you combine multiple operations into a single request. One batch request that processes 100 items is better than 100 individual requests.
Check your code for loops. A common mistake is making API calls inside a loop without any delay or deduplication. A loop that processes 10,000 records and makes an API call for each one will exhaust most rate limits within seconds.
As a web scraper or crawler
If you are scraping a website or running an automated crawler and receiving 429 errors, the site’s rate limiting is working as intended. Web servers enforce request limits to protect resources and prevent a single client from consuming disproportionate bandwidth.
Most legitimate web crawlers (Googlebot, Bingbot) respect
robots.txt
and use
Crawl-delay
directives. If you are building a scraper, implement the same courtesy:
- Respect
robots.txt - Add a delay between requests (1-5 seconds minimum)
- Use the
Retry-Afterheader when you receive a 429 - Identify your bot with a descriptive User-Agent string
- Do not ignore rate limits by rotating IP addresses – this escalates from rate limiting to a permanent ban
As a developer debugging a 429
When your application starts returning 429 errors to your users because your backend is getting rate-limited by an upstream API, the fix is in your application code, not on the API provider’s side.
Add a request queue. Instead of making API calls directly from request handlers, push them onto a queue and process them at a controlled rate. This decouples user-facing response time from API rate limits. Most frameworks have job queue systems (Bull in Node.js, Celery in Python, Laravel Queue in PHP).
Implement circuit breaker patterns. After receiving a 429, stop making requests for the duration specified in
Retry-After
. Do not let every incoming user request trigger another API call that will also fail. A circuit breaker detects the rate-limited state and short-circuits the call, returning a cached response or a graceful error instead.
Log rate limit events. Every 429 response from an upstream API should be logged with the endpoint, timestamp, and rate limit headers. This data tells you whether you are consistently near the limit (and need to optimize) or if a sudden spike caused a one-time event. Check your error logs for patterns.
Cloudflare 429 errors#
Cloudflare has its own rate limiting rules that apply before the request reaches your origin server. If Cloudflare returns a 429, the request never reached your server at all.
Cloudflare 429 errors come from two sources:
Cloudflare Rate Limiting rules that the site administrator configured. These are explicit rules like “block any IP that makes more than 100 requests per minute to /api/*.” The response page usually includes a Cloudflare-branded error page with a Ray ID.
Cloudflare Bot Management that detects automated traffic patterns and challenges or blocks them. This can affect legitimate users who are behind VPNs, corporate proxies, or Tor exit nodes.
How to tell if the 429 is from Cloudflare: Check the response headers for
cf-ray
and
server: cloudflare
. If these are present, Cloudflare generated the 429, not the origin server.
If you are the site owner and your legitimate users are getting Cloudflare 429 errors, review your rate limiting rules in the Cloudflare dashboard. The threshold may be too aggressive, or the rule may be matching URLs it should not.
Server-side: configuring rate limiting properly#
If you are a server administrator, rate limiting protects your infrastructure but should not block legitimate users.
Nginx rate limiting
Nginx can enforce request rate limits per IP:
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api burst=20 nodelay;
limit_req_status 429;
}
}
This allows 10 requests per second per IP with a burst allowance of 20. The
limit_req_status 429
directive tells Nginx to return a 429 instead of the default 503 when the limit is exceeded.
Key decisions:
- rate – how many requests per second to allow. Too low catches legitimate users. Too high offers no protection.
- burst – how many requests can exceed the rate before limiting kicks in. A burst of 20 means a client can send 20 requests at once, then must slow to the sustained rate.
- nodelay – process burst requests immediately rather than queuing them. Without
nodelay, Nginx queues excess requests and releases them at the configured rate, which adds latency.
WordPress-specific rate limiting
WordPress login pages and XML-RPC endpoints are the most common targets for brute force attacks. Rate limiting these endpoints specifically is more effective than applying a blanket limit to the entire site:
location = /wp-login.php {
limit_req zone=login burst=5;
limit_req_status 429;
# ... fastcgi_pass etc.
}
This allows normal login behavior but blocks automated scripts that hammer the login page with hundreds of attempts per minute.
For WordPress-specific 429 troubleshooting (security plugins, WooCommerce checkout, block editor save failures), see the dedicated WordPress 429 too many requests guide.
When rate limits are too tight
Signs that your rate limits are catching legitimate users:
- Customer support tickets about being blocked
- High bounce rates from specific IP ranges (corporate networks)
- WooCommerce checkout failures during sale events
- AJAX-heavy page builders failing to save
If legitimate users hit the limit, either raise the threshold or exclude specific endpoints from rate limiting. A WooCommerce checkout that makes 15 AJAX requests during a single transaction should not trigger a per-IP limit set to 10 requests per minute.
The Retry-After header#
If you are implementing rate limiting on your server, always include a
Retry-After
header in 429 responses. This tells clients exactly how long to wait:
Retry-After: 30
Or as an HTTP date:
Retry-After: Wed, 08 Apr 2026 14:30:00 GMT
Without this header, clients have to guess how long to wait, and they often guess wrong – either retrying too soon (extending their block) or waiting too long (unnecessary delay). Well-behaved API clients check for
Retry-After
and respect it automatically.
Diagnosing where the 429 comes from#
When you see a 429, the first question is which layer generated it. The response headers tell you:
Check for Cloudflare headers. If the response includes
server: cloudflare
and a
cf-ray
header, Cloudflare generated the 429 before the request reached your server. Review your Cloudflare rate limiting rules.
Check the server’s access log. If the 429 appears in your Nginx or Apache access log, the web server generated it. Check your
limit_req
configuration in Nginx or
mod_ratelimit
in Apache.
Check for plugin-specific headers. WordPress security plugins like Wordfence sometimes add custom headers (like
X-WF-Block
) to their responses. If these are present, the plugin is generating the 429, not the web server.
Check if the 429 is from an upstream API. If your application makes API calls and the 429 appears in the API response (not in your server’s access log), the rate limit is on the API provider’s side.
Running a quick test with
curl
shows you the full response headers:
curl -I https://yoursite.com/page
The
-I
flag returns only the headers, which is enough to identify the source. Look at the
server
header, any
X-RateLimit-*
headers, and the
Retry-After
value.
429 errors on Hostney#
On Hostney, rate limiting is enforced at the server level to protect all accounts from abuse. The most common scenario where legitimate users encounter a 429 is after multiple failed login attempts on the WordPress login page.
Rate limit bans expire automatically. If you are locked out after too many failed login attempts, wait 15 minutes and try again. If the ban persists, check your IP status through the control panel or contact support.
For customers building applications that make API calls to external services, implement exponential back-off and response caching in your code. If your WordPress plugins are generating 429 errors from third-party APIs, check the plugin’s settings for request frequency options, or contact the API provider about increasing your rate limit allocation.