A 429 Too Many Requests response means that a client has sent more requests than a rate limit allows during a period of time. The client may be a real visitor, a search crawler, an API integration, or an unwanted bot. Access problems occur when the limit is too low, applied at the wrong layer, or enforced without a safe retry response.
Rate limiting is used to control request bursts and reduce unwanted traffic. It can be configured in the website server, a bot-protection system, a reverse proxy, or a shared hosting environment. A useful first step is to identify which layer returned the 429 response.
Table of Contents
How rate-limiting mistakes cause a 429 response
Burst limits are too strict
A burst limit controls how many requests a client may send in a short period. A visitor loading several page resources at once, a crawler fetching many pages, or an API client sending requests in parallel can exceed the limit even when the traffic is legitimate. A limit designed only for slow, one-at-a-time browsing can block normal bursts.
Review whether the limit is based on a short burst, a longer request window, or both. Adjust the rule only after checking which traffic is being affected. Raising a limit for every request can increase server load, so a safer change is to target the affected endpoint, client group, or trusted service where the configuration allows it.
Bot protection treats useful traffic as unwanted
Bot protection can restrict automated requests. Some automated traffic is useful, including search engine crawlers, while other bots can create spam, malicious activity, or excessive load. The distinction matters because a broad rule may throttle both unwanted bots and legitimate crawlers. Unwanted bots can overload a server, distort analytics data, and attempt spam or malicious activity.
Check whether the rule matches all automated clients, a user-agent pattern, an IP address, or a request path. Keep protection on sensitive or expensive endpoints, but avoid applying the same strict rule to public pages and critical services without reviewing their traffic patterns.
Shared hosting applies a limit outside the website configuration
On shared hosting, rate limiting or resource protection may affect more than one website process. A site owner may change an application rule and still receive 429 responses because the request is being limited by the hosting environment or another service in front of the site.
Compare the time and source of the 429 response with the logs available to the website. If the application does not record the request, or if the response has the format of an upstream service, the limit may be outside the application. This distinction prevents repeated changes to the wrong configuration.
A reverse proxy applies a different rule than the origin server
A reverse proxy receives requests before forwarding them to the website server. It may apply its own request limit, bot rule, or burst policy. In that case, the origin server may not see every request that visitors report as blocked. A proxy can also identify clients differently from the origin, which can make several users appear to share one rate-limit key.
Check each layer in request order: the visitor or API client, the reverse proxy, the hosting environment, and the origin application. The first layer that records the rejected request is the likely source of the 429 response.
How to confirm the source in logs
Use the same URL, client, and approximate time as the reported failure. Then compare records across the layers that handle the request.
- Record the affected request. Note the URL, request method, client or crawler, time of the response, and whether the problem affects one endpoint or the whole site.
- Check the application log. If the request reaches the application, look for the response and the rule or limit that rejected it.
- Check the reverse-proxy or protection log. A 429 recorded there but not in the application indicates that the request was stopped before it reached the origin.
- Compare several clients. If many visitors are blocked together, the limit may use a shared address, proxy identity, or broad rule. If only one client is affected, the limit may be tied to that client or its request pattern.
- Check the response guidance. A
Retry-Afterheader tells a client when to try again. If it is absent, clients cannot use a server-provided retry time and may retry too soon.
Safe recovery after legitimate traffic is throttled
- Pause repeated retries. A client that immediately repeats a rejected request can extend the burst and continue the rate limit.
- Use the Retry-After value when it is present. Wait for the stated period before trying again.
- Use controlled retries when it is absent. Add increasing delays between attempts instead of sending requests continuously. Keep the retry process bounded so one failure does not create a request loop.
- Identify the affected traffic. Separate real users, known API clients, search crawlers, and unwanted bots before changing a rule.
- Adjust the narrowest rule. Increase the burst or request allowance only for the endpoint, client group, or layer confirmed by the logs.
- Protect critical endpoints separately. Login, payment, account, and API endpoints may need stricter limits than public content. Apply changes with care so that protection is not removed from sensitive paths.
- Test after the change. Confirm that normal visitors and approved automated clients can access the required pages, while the intended protection remains active.
How to avoid blocking real users and search crawlers
Do not treat every automated request as unwanted. Search crawlers can be useful, while unwanted bots can create spam, malicious activity, excessive server load, and inaccurate analytics. Bot controls should distinguish useful crawlers from traffic that should be restricted.
Review rules by endpoint and traffic type. Public pages may need to tolerate normal visitor bursts. Expensive or sensitive endpoints can use tighter limits. API clients should use deliberate retry delays, and the service should provide Retry-After when a temporary limit is reached.
429 versus 403
| Response | Meaning | Typical focus |
|---|---|---|
| 429 Too Many Requests | The request rate has exceeded a configured limit. | Check bursts, retry handling, client grouping, and the layer applying the limit. |
| 403 Forbidden | The server understood the request but refuses access to the resource. | Check access rules and permissions rather than retrying repeatedly. |
A 403 is an access denial, while a 429 is a request-rate response. A 403 error means that access to the requested resource has been denied. Treating a 429 as a permanent access block can lead to the wrong configuration change.
When to contact support
Contact support when logs show that the 429 is generated by a hosting or upstream layer that you cannot change, when shared hosting appears to group unrelated visitors, or when the response source remains unclear after comparing the available logs. Include the affected URL, response time, client type, and the relevant log entries so the rate-limiting layer can be identified efficiently.