Skip to content
Rescue 404
Rescue

Server Errors

429 Too Many Requests

Intermediate Risk: medium

Last reviewed

Hosting access often needed Database access usually not needed

Direct answer

429

HTTP 429 Too Many Requests means a rate limit, bot challenge, or abuse rule stopped this client from making more requests for a while—wait out Retry-After if present, then identify which layer (host, Cloudflare, security plugin, or API) is throttling before cutting limits that protect the site.

429 is a deliberate throttle, not a crash and not the same as 403 Forbidden or 503 Service Unavailable. On WordPress and proxied sites it often appears after login brute-force protection, Cloudflare rate limiting, host connection caps, or a runaway cron/plugin. This guide shows how to find the limiting layer, cool down safely, and restore legitimate traffic without disabling every defense.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • HTTP 429 Too Many Requests indicates the user has sent too many requests in a given amount of time. (429 Too Many Requests)
  • RFC 6585 defines 429 Too Many Requests for rate limiting and notes that a Retry-After header may indicate how long to wait. (RFC 6585 §4)
  • Cloudflare rate limiting rules can match request characteristics and enforce thresholds that return rate-limit responses at the edge. (Rate limiting rules)

What the error means

HTTP 429 tells the client that it has exceeded a request budget for a given window. The server understood the request and is refusing more of the same kind for a period of time—often with a Retry-After header. That differs from 403 (policy denied access regardless of rate), 401 (authentication failed), and 503 (service overloaded or down for maintenance). Rate limits can sit at the origin (Apache/nginx modules, host panel “connections per IP”), at Cloudflare (Rate limiting rules, Bot Fight, WAF custom rules), or inside WordPress (security plugins, login lockouts, REST/API throttles). The fix is to identify which layer returned 429 and whether the traffic is abusive, misconfigured automation, or a false positive on a shared IP.

Common symptoms

  • Browser or API client shows “429 Too Many Requests” or a host/Cloudflare branded rate-limit page
  • DevTools Network confirms status 429, sometimes with a Retry-After response header
  • Problem hits only some IPs, offices, VPNs, or after many refreshes/logins—not every visitor
  • wp-login, xmlrpc.php, admin-ajax, REST, or checkout endpoints fail while the homepage still loads
  • Issue started after enabling Cloudflare rate limiting, a security plugin, or a host “protect” feature
  • Cron jobs, uptime monitors, or staging sync tools suddenly fail with 429 while humans can browse
  • Waiting a few minutes restores access, then the limit trips again under the same traffic pattern

Most likely causes

  1. 01 Cloudflare Rate limiting rules, Bot Management, or WAF custom rules matching legitimate paths
  2. 02 Host-level connection or request-per-IP caps (LiteSpeed, ModSecurity, Imunify, cPanel protection)
  3. 03 WordPress security plugin login/firewall lockouts after failed attempts or shared NAT IPs
  4. 04 Brute-force or scraper traffic that trips a correct limit and also blocks nearby legitimate clients
  5. 05 Runaway plugin, theme, or custom script looping admin-ajax, REST, or XML-RPC requests
  6. 06 Misconfigured monitoring, SEO crawler, or CI job hitting the same URL too aggressively
  7. 07 CDN or reverse-proxy duplicate counting when both edge and origin enforce overlapping budgets

What changed before the problem started

  • Cloudflare rate limiting, Bot Fight Mode, or a WAF rule was enabled or tightened
  • Security plugin installed or lockout thresholds lowered after an attack
  • Host applied new connection limits or ModSecurity rate signatures
  • A new uptime monitor, backup sync, or marketing crawler started hitting the site
  • Plugin update introduced a polling loop against admin-ajax or the REST API
  • Office moved behind a shared NAT/VPN so many users share one public IP

Troubleshooting steps

  1. 01

    Confirm 429 and capture Retry-After and which URL fails

    In DevTools → Network, verify status 429 (not 403/503), note the exact path, and read Retry-After if present. Screenshot the response body and headers. Scope matters: login-only 429 points at lockout rules; sitewide 429 points at edge or host IP budgets.

  2. 02

    Wait out a short cool-down, then retest from another network

    If Retry-After is seconds to a few minutes, pause automated retries and try again once. Retest from a phone hotspot. If only one network fails, the limit is IP-based and you should whitelist or raise the threshold for that path—not disable every rule.

  3. 03

    Check Cloudflare Security and Rate limiting events

    In Cloudflare, open Security → Events (and Rate limiting rules) for the Ray ID or client IP at the failure time. If Cloudflare issued the 429, adjust the matching rule, exclude trusted paths like `/wp-admin/` for your IP, or raise the threshold carefully. Purge is irrelevant; this is not a cache bug.

  4. 04

    Review WordPress security-plugin lockouts via FTP if needed

    If wp-admin or wp-login returns 429/lockout pages, check the security plugin’s lockout/block list for your IP. Rename the plugin folder under `wp-content/plugins` only long enough to regain admin, whitelist your IP, then restore the plugin with saner thresholds.

  5. 05

    Ask the host whether origin rate limits or ModSecurity fired

    When Cloudflare shows no matching event, send the host the timestamp, client IP, and URL. Shared hosts often enforce per-IP connection caps that return 429. Ask which rule fired before requesting a permanent disable of protection.

  6. 06

    Stop runaway loops and aggressive monitors

    Disable or slow any new crawler, uptime check under a few minutes, or plugin that polls admin-ajax in a tight loop. Fixing the requester often clears 429 without weakening the site for real attackers.

When to stop troubleshooting

Escalate when you cannot see Cloudflare or host rate-limit logs, lockouts keep returning after safe whitelist changes, checkout or lead forms stay throttled during business hours, or you suspect an active attack that needs professional WAF tuning. Provide the 429 URL, Retry-After value, client IP, Ray ID if any, and which layer’s event log shows the hit—do not permanently remove all rate limits just to silence the code.

Information to collect before requesting help

  • 01 Exact URL returning 429 and whether wp-admin/login is affected
  • 02 Retry-After header value if present
  • 03 Client public IP and whether another network still fails
  • 04 Cloudflare Security/Rate limiting event or Ray ID (if proxied)
  • 05 Host ModSecurity / connection-limit log excerpt
  • 06 Security plugin lockout settings and recent blocks
  • 07 Any new monitors, crawlers, or plugin updates in the last 48 hours

How a professional repairs the problem

We confirm the true 429 scope, read edge and origin rate-limit events to the rule that fired, cool down false-positive IPs, and retune thresholds by path instead of disabling protection. Runaway loops and aggressive monitors are stopped, WordPress lockouts are cleared with IP allowlists restored, and we verify homepage, login, checkout, and APIs survive a realistic traffic pattern before re-enabling stricter rules.

Frequently asked questions

Is 429 the same as the site being down? +
Not usually. 429 means a limiter refused more requests from a client or pattern. Other visitors may still browse. Treat it as a throttle to diagnose, not automatically as a full outage.
How is 429 different from 403 Forbidden? +
403 is an access denial that typically will not clear just by waiting. 429 is budget-based and often recovers after Retry-After or when the client slows down.
Can Cloudflare return 429 even if WordPress is healthy? +
Yes. Edge rate limiting and bot rules can answer 429 before WordPress runs. Check Cloudflare Security events first when the hostname is orange-cloud proxied.
Should I turn off all rate limiting to fix 429? +
No. Identify the rule and path, whitelist trusted IPs, or raise a specific threshold. Blank disables invite brute-force and scraper storms that create worse outages.
Why do only office users hit 429? +
Shared NAT or VPN egress makes many people look like one IP. Login and API budgets then trip for the whole office. Allowlist that egress IP or raise the threshold for authenticated staff paths.
Does clearing cache fix 429? +
Almost never. Cache purge does not reset rate-limit counters. Fix the rule, the client behavior, or wait out the window.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.