HTTP 429 Too Many Requests: What It Means and How to Fix It

What this error means & how to recognize it

• A browser, API client, monitoring tool or checker receives 429 Too Many Requests.
• The response may affect one URL, API route, HTTP method, IP address, account or client rather than the whole site.
• Requests may begin working again after a delay, which is consistent with a temporary rate limit.
• The response may include Retry-After or other rate-limit-related headers.
• DNS can resolve and TLS can succeed because the request reached an HTTP-speaking endpoint; those checks do not prove that the request is permitted at the application layer.
• Different clients or networks may receive different results when the limit is scoped to an IP, identity, token or session.

Root causes, ordered by likelihood

1. A request-rate limit was exceeded. The application, API gateway or web server may limit requests by IP address, account, session, API key, route or another client identity.
2. A proxy, CDN or WAF applied its own policy. An intermediary can return 429 before the request reaches the origin server.
3. Automated traffic is sending requests too quickly. Crawlers, monitoring checks, scripts, retries or parallel workers can trigger a limit even when individual requests appear valid.
4. A client is retrying without backoff. Repeated retries after failures can keep the client inside the limit window or intensify load.
5. A configuration or deployment changed the effective threshold. A recent rule, routing change, authentication integration or proxy policy may have altered which requests are counted or limited.
6. The limit is intentional but the client workflow is incompatible with it. For example, a batch process may need pacing, connection reuse or an approved request quota rather than repeated immediate retries.

How to fix it

For visitors and API consumers

1. Stop rapid refreshes, parallel requests and automatic retries while investigating.
2. Check the response headers for Retry-After. If it is present, wait for the stated delay or time before retrying.
3. Retry the exact URL or API endpoint with the same method after the delay. Do not switch methods or repeatedly vary requests just to evade the limit.
4. If you control the client, use bounded retries with exponential backoff and jitter, and respect the service’s documented request quota. Avoid retrying requests that are not safe to repeat unless the API defines their retry behavior.
5. Check whether the problem affects one client, account, API key, network or endpoint. A different result from another client does not by itself identify the cause.
6. If the 429 persists, contact the site or API owner with the endpoint, method, timestamp, response headers and a description of request frequency. Remove cookies, authorization values and API secrets from anything you share.

For site owners and developers

1. Reproduce the response with the smallest authorized test that matches the affected method, URL, client identity and request rate. Record the status, timestamp and relevant response headers.
2. Identify the generating layer. Check the CDN or WAF response details, reverse-proxy logs, web-server logs and application logs in the order that matches your architecture. Do not assume the origin generated the response.
3. Search the relevant logs for the same timestamp, route, client identifier and rate-limit decision. Determine what is being counted and which limit window or policy was applied.
4. Compare the affected request with a normal request. Check the HTTP method, authentication context, source identity, route, caching path and recent deployment or configuration changes.
5. If the limit is intentional, improve the client guidance: return an accurate Retry-After value where appropriate, document quotas, and ensure clients can use controlled backoff rather than tight retry loops.
6. If the limit is incorrect, apply the narrowest authorized correction at the layer that generated the response. Validate its effect on the affected route without weakening unrelated security or abuse protections.
7. Retest the same request and rate, then test representative neighboring routes and client identities. Confirm that intentional limits still work and that the response no longer blocks legitimate traffic.

Prevention & how to verify the fix

• Define and document request quotas, limit scope and retry behavior for APIs and automated clients.
• Return useful rate-limit information, including Retry-After when appropriate and supported by the service design.
• Implement bounded exponential backoff with jitter in clients instead of immediate repeated retries.
• Monitor 429 rates by route, client identity, network and deployment so broad increases are distinguishable from isolated abuse or misbehaving clients.
• Keep CDN, WAF, proxy, server and application rate-limit settings version controlled and review changes before release.
• Test important API methods and public routes after deployments, including expected behavior when a threshold is reached.
• Retain enough sanitized request and policy-decision logging to match a 429 response to the component that generated it.

Frequently asked questions