A 429 Too Many Requests response means a server-side component is limiting requests. On WordPress, that component may be a CDN, hosting control, security plugin, or application integration. Find which layer generated the response before changing login limits or deactivating protection.
Stop repeatedly refreshing the blocked action. The response may include a Retry-After header. MDN's 429 reference explains the status and retry signal. Respect the indicated wait where present rather than increasing traffic during the incident.
Capture One Failed Request
Use the browser Network panel to identify the exact request. A login page can load successfully while its next request fails. An editor can appear frozen because admin AJAX or a REST call is limited, even though the document request returns 200.
Record the URL path, method, time with timezone, status, request ID, response headers, and a redacted error message. Do not share cookies, authorization headers, passwords, or a full form payload.
A single read-only check on your own site can capture headers:
curl -sS --max-time 15 -D - -o /dev/null https://example.com/wp-login.php
That request does not reproduce an authenticated browser session. Use it as a comparison, not as proof that the user's failing workflow now works.
Join the Response to the Right Log
Look for the request ID or timestamp in CDN and WAF events first, then host access logs and plugin logs. An edge-generated block may never reach WordPress. Deactivating a plugin cannot fix a rule that rejects the request before the origin.
If many unrelated users are blocked together, examine visitor identity. A proxy misconfiguration can make everybody look like the same source address. Use the Wordfence and CloudFront client-IP guide before raising thresholds to compensate for an identity problem.
Verification record for WordPress 429 Too Many Requests: Diagnose Admin and Login Lockouts. Fill in your own evidence.
Distinguish Normal Activity From a Request Loop
Compare a single-tab session with the failing session. Review repeated editor requests, multiple open dashboards, monitoring tools, and integrations that retry immediately after failure. Do not generate a load test against production to discover the threshold.
For a shared office network, several legitimate users may share an external address even when proxy detection is correct. The rule must be evaluated against that actual usage pattern. For a noisy custom integration, implement the destination's documented backoff and retry behavior rather than allowing unlimited requests.
Make a Narrow Correction
| Evidence |
Appropriate next step |
| Incorrect visitor IP |
Repair trusted-proxy configuration |
| One plugin request loop |
Fix the loop or pause that integration |
| A false-positive path rule |
Review a scoped rule adjustment |
| Genuine abusive traffic |
Keep protection and investigate the source |
| Hosting resource control |
Ask the host for the specific limit and capacity evidence |
Do not globally disable the WAF or permanently allowlist all admin traffic. Document any temporary exception, its owner, expiration, and reversal method.
Confirm Both Usability and Protection
Repeat a normal login, edit, save, and any affected form or checkout action after the retry window. Check that the request rate is ordinary and that logs no longer show the false positive. Confirm the intended security rule still exists; a page loading after every defense was removed is not a satisfactory fix.
For a recurring lockout, HandL WP can trace the limiter. The most useful starting evidence is one timestamped failed request and the network path, not a list of plugins disabled at random.
References checked September 29, 2026. Diagrams and examples are explanatory, not measured customer results.