HTTP 429 in monitoring: when a request limit blocks the check
The monitor receives Too Many Requests while a visitor can open the site. Find the rejecting rule, investigate a shared limit and verify the actual impact.
Monitoring reports an error, but opening the site in a browser does not reproduce it. The check receives HTTP 429 Too Many Requests: the request encountered rate limiting. Establish where the limit applies and to whom, then assess user impact separately. This guide covers HTTP checks; configuration examples use NGINX and Cloudflare, and the diagnostic curl example assumes Linux.
First identify the layer that rejected the request
Save the exact URL, method, time, measurement location and check response. For one read-only URL, you can run curl -sS -D - -o /dev/null https://example.com/health. The domain and path are examples; replace them with your own. The command displays headers and discards the body. Record the status and any Retry-After. Confirm the connection to a particular rule in the available logs.
Work through the CDN, reverse proxy and application. With Cloudflare, check the relevant rate limiting rule, its expression, counting characteristics and period. With NGINX, inspect limit_req and limit_req_status; this module's default rejection status is 503. The number 429 alone therefore does not identify a particular module. Connect it to rejection evidence at the correct layer before changing the monitor's settings.
Find which checks consume the same limit
Check the key that groups requests for the rule. NGINX can use $binary_remote_addr, for example, which represents the client address. Multiple monitors with a shared outbound IP can therefore consume the same limit. Count their frequency, concurrent runs and additional attempts within that key. Looking at just one monitor may leave part of the traffic out.
Behind a proxy, verify which address the server actually uses. In NGINX, restoring the client address involves set_real_ip_from and real_ip_header: replacement addresses need to come from a trusted proxy. X-Forwarded-For alone, without verifying trust, does not establish the client's true identity. Compare the result with logs and configuration. Make the same assessment for a limit attached to a test account or API key.
Respect the wait and adjust the check schedule
A 429 response may include Retry-After, but the header is optional. Its value can be an HTTP date or a number of seconds to wait after receiving the response. Check how the monitor interprets it and whether the next attempt actually waits. A missing header alone does not determine a suitable interval. Derive that from the rule and the required detection speed.
Spread checks that start together and limit unnecessary repeat attempts. Account for the mitigation duration too; Cloudflare defines it as a separate rule parameter. One successful request after a pause does not verify the entire normal schedule. First test the change with a small number of checks, then at the expected concurrency. Preserve service protection and fit the measurement to its purpose and capacity.
Confirm the outcome for an ordinary client too
After the change, compare monitor results with rejected requests and application response times. Include an independent, proportionate check over the visitor's normal route. Verify that the monitor still follows an important function rather than just an easier URL that escapes the restriction. If you prepare a dedicated read-only check, define what it verifies and which failures it no longer covers.
If legitimate users receive 429 too, treat their access as a real operational problem. If only measurement traffic is restricted, record that cause and correct its configuration. In both cases, save the rule, affected key and verification result. The next incident can then begin with evidence about whether the service or its check is unavailable.
- Connect the response to a specific layer and rule.
- Count checks and attempts sharing the same limit.
- Verify Retry-After, scheduling and mitigation duration.
- Confirm the monitored function is available to visitors too.
What to take away
Interpret HTTP 429 in the context of a particular rule and client. Find the shared counting key, align measurement with the limit and verify the outcome over the user route. This separates a check problem from a restriction that actually affects the service.
