HTTP 429 means the website, API, CDN, WAF, or gateway is refusing the request because a rate limit has been reached. Uptime Basics labels an unaccepted 429 as Rate limited.
One 429 check does not automatically make the monitor Down. Availability changes only after the normal consecutive and regional confirmation requirements are met.
Find the limiting layer
- Open Detailed Logs and confirm the HTTP 429 timestamp.
- Review the regional Confirmation details.
- Check CDN, WAF, gateway, reverse-proxy, and application logs.
- Identify which rule, identity, path, or traffic group reached its limit.
- Compare the rule window with the monitor's configured interval.
The limit may apply to more than this monitor. Customer traffic, deployment checks, search crawlers, security scans, and other monitoring tools can share the same rule.
Reduce unnecessary requests
If one-minute checks are not required, choose a five-minute or longer interval. A longer interval can reduce repeated 429 responses, but it should not be used to hide an unexpectedly restrictive or misconfigured rule.
Also check for:
- duplicate monitors for similar endpoints;
- redirect chains that touch several protected routes;
- a health endpoint that performs expensive work;
- retries or probes from other systems; and
- a rate rule that groups all regions or automated clients together.
New one-minute monitors that are already rate limited during setup can temporarily run at a five-minute interval while the target proves stable. The configured interval is restored after three successful checks or when the 24-hour onboarding protection expires.
Create a monitoring-safe health endpoint
The safest long-term approach is usually a lightweight endpoint with a narrow security rule. It should return only the minimum health information and should not expose customer data, environment variables, stack traces, or secrets.
If needed, require a dedicated custom header or HTTP Basic Authentication and allow only the endpoint and request pattern that monitoring needs. Do not disable rate limiting or bot protection for the entire website.
Regional differences
Multi-region confirmation can reveal whether only one monitoring route is being limited. A rule that allows one region but rejects two others can still confirm a failed cycle.
Review whether the rule is intentionally regional. If customers in those regions should have access, the 429 may represent a real availability problem rather than a monitoring exception.
Should you accept HTTP 429?
Accepting 429 is rarely appropriate for a customer-facing website because it marks rate-limit rejection as healthy.
Use an accepted 429 only when that exact response is the documented healthy result for a specialized endpoint and it still represents the service condition you intend to measure. Once accepted, future 429 responses count as Up and no Rate limited diagnosis is recorded.
When to contact Support
Contact Support when target logs do not show a matching rate-limit event or when a narrow monitoring rule is configured but 429 responses continue.
Include the monitor name, URL, interval, failed timestamps, affected regions, and the security or gateway product involved. Do not include rule credentials, authorization values, cookies, passwords, or private keys.