The short version
- 01Pause repeated refreshes, polling and automatic retries when a 429 appears.
- 02Wait for the Retry-After delay or date when the response supplies one.
- 03Read the provider's limit documentation rather than assuming a universal reset time.
- 04Reduce request concurrency and remove unnecessary repeated calls in API clients.
- 05Use bounded retries with increasing delays when the provider permits retrying.
- 06Check shared usage and contact the provider if expected traffic remains limited.
Raw message
429 Too Many Requests
Likely causes
- Too many requests within the service's counting window.
- A script, poller or retry loop repeatedly calling the same service.
- Several clients sharing a limited account, application or network identity.
- A burst of concurrent requests exceeding a provider-specific limit.
The code identifies a limit, not its reset time
429 says too many requests arrived within a period of time. The standard leaves the counting method and user identification to the service: a limit can apply to a resource, account or group of servers. It is not necessarily a permanent ban or a limit tied only to your IP address.
An API returning 429 may include an explanation and a Retry-After header. The code alone does not promise that waiting one minute will work. Check the service's actual response and documentation.
If a website says you are trying too often
Pause repeated attempts and follow any displayed waiting period. Close an unnecessary auto-refreshing view or stop an automation you control. A shared account or network may contribute traffic, so one quiet browser does not necessarily mean the limited identity has stopped making requests.
Our recommendation is to report persistent limits with the action, time and error identifier. Do not keep probing for the exact threshold. The service owner can explain how its particular limit is counted.
If you maintain the API client
Retry-After accepts either a delay in seconds or an HTTP date. For example, Retry-After: 120 asks for a two-minute delay after receiving the response; it does not mean 120 milliseconds. Wait at least as instructed before a permitted retry.
GitHub's REST API guidance illustrates the client-side remedy: avoid unnecessary polling, queue requests instead of sending bursts, and respect its retry or reset headers. Its documented headers and limits are GitHub-specific. Other APIs need their own policy; do not copy a quota or reset interval from an unrelated provider.
For repeated failures, use increasing delays and a finite retry budget, then surface the error. A waiting retry loop should not create more workers that send additional requests. On the server side, RFC 6585 prohibits caching a 429 response, so check that an intermediary is not replaying a stale limit page.
Sources and review notes
Checked on . Based on RFC 6585, MDN and GitHub's documented API practices. GitHub is an implementation example; each provider defines its own limits and retry policy.