What does HTTP 429 Too Many Requests mean?

The server is refusing requests because you sent more than its limit allows in the current window. RFC 6585, which defines the code, says the response may carry a Retry-After header saying how long to wait. GitHub answers a request over its primary limit with 403 or 429 and x-ratelimit-remaining set to 0.

How long should I wait after hitting a rate limit?

Until the time the API gives you. Retry-After holds a number of seconds, and GitHub's x-ratelimit-reset holds the reset time in UTC epoch seconds. The calculator has no clock, so the seconds it shows for an overshoot are only the surplus divided by the average rate, not the time to the reset.

How do I convert a rate limit to requests per second?

Divide the limit by the window in seconds. 100 requests per minute is 100 ÷ 60 = 1.67 per second, and 10,000 per day is 10,000 ÷ 86,400 = 0.12 per second. Spacing requests at that rate never runs out before the window ends. The calculator also shows that spacing as a minimum gap, window ÷ limit: 600 ms for 100 per minute and 720 ms for 5,000 per hour.

Can I send all my remaining requests at once?

In a plain fixed window, yes: 800 remaining can go out together. Many APIs also cap bursts or limit each endpoint separately, and GitHub has secondary limits on top of the hourly one, so a large burst can be refused even with requests left. The calculator models one fixed window only.

API Rate Limit Calculator

Enter an API rate limit, its window in seconds, minutes, hours or days, and the requests used and queued to get percent used, requests left and pacing. How it works

Rate limit

Time window

Window unit

Requests used

Requests queued (optional)

Requests remaining

100

Usage 0% · Allowed rate 1.67/s

Usage0%

00 / 100 requests100

Minimum gap between requests

600 ms

Window ÷ limit: an average spacing that never runs out before the window ends, not the wait after a 429.

About the API Rate Limit Calculator

A rate limit of 5,000 requests per hour, GitHub's limit for an authenticated user, averages 1.39 requests per second (5,000 ÷ 3,600). Enter the limit, the window in seconds, minutes, hours or days, the requests already used and any still queued, and the calculator shows the percent used, the requests left in the window, that average rate, the minimum gap between requests (720 ms here) and whether the queue would go over.

Average allowed rate for common limits

Limit	Window (seconds)	Requests per second	Minimum gap
60 per minute	60	1.00	1,000 ms
100 per minute	60	1.67	600 ms
60 per hour	3,600	0.02	60,000 ms
1,000 per hour	3,600	0.28	3,600 ms
5,000 per hour	3,600	1.39	720 ms
10,000 per day	86,400	0.12	8,640 ms

Requests per second is limit ÷ window, rounded to two decimals as the calculator shows it; the minimum gap is window ÷ limit in milliseconds. 60 and 5,000 per hour are GitHub's REST API limits without and with authentication.

How to use this tool

Enter the rate limit and the length of its window, and pick the unit: seconds, minutes, hours or days. 1 hour is the same as 3,600 seconds.
Enter the requests already used in this window. Many APIs report it in a header, such as GitHub's x-ratelimit-used.
Optionally enter the requests still waiting to be sent.
Read the usage meter, the requests remaining, the average allowed rate and the minimum gap between requests. With a queue, Queue Impact shows the usage after sending it and by how many requests it overshoots.

Frequently asked questions

What does HTTP 429 Too Many Requests mean?: The server is refusing requests because you sent more than its limit allows in the current window. RFC 6585, which defines the code, says the response may carry a Retry-After header saying how long to wait. GitHub answers a request over its primary limit with 403 or 429 and x-ratelimit-remaining set to 0.
How long should I wait after hitting a rate limit?: Until the time the API gives you. Retry-After holds a number of seconds, and GitHub's x-ratelimit-reset holds the reset time in UTC epoch seconds. The calculator has no clock, so the seconds it shows for an overshoot are only the surplus divided by the average rate, not the time to the reset.
How do I convert a rate limit to requests per second?: Divide the limit by the window in seconds. 100 requests per minute is 100 ÷ 60 = 1.67 per second, and 10,000 per day is 10,000 ÷ 86,400 = 0.12 per second. Spacing requests at that rate never runs out before the window ends. The calculator also shows that spacing as a minimum gap, window ÷ limit: 600 ms for 100 per minute and 720 ms for 5,000 per hour.
Can I send all my remaining requests at once?: In a plain fixed window, yes: 800 remaining can go out together. Many APIs also cap bursts or limit each endpoint separately, and GitHub has secondary limits on top of the hourly one, so a large burst can be refused even with requests left. The calculator models one fixed window only.

Planning requests against an API quota

Before a batch job or sync script runs against an API that caps requests per time window, enter the limit, the window in seconds, minutes, hours or days, the requests already spent and the ones still waiting in your queue. The tool tells you whether the queue fits in what is left of the window and, if not, by how many requests it overshoots.

GitHub's REST API gives an authenticated user 5,000 requests an hour (window 1, unit hours). With 4,200 used and 1,000 queued, the tool shows 84% used, 800 remaining, an average allowed rate of 1.39 requests a second and a minimum gap of 720 ms between requests. Sending the whole queue would take usage to 104%, 200 requests over. At 1.39 a second those 200 take about 144 seconds, which is a pacing figure, not a safe delay: in a fixed window the surplus can only go out after the window resets, so send 800 now and the rest after the time in the reset header.

How the figures are derived

usage = used ÷ limit × 100, remaining = max(0, limit − used), pace = limit ÷ window, gap = window ÷ limit × 1,000 ms

The window is converted to seconds first (a minute is 60, an hour 3,600, a day 86,400). 100 requests per minute gives a gap of 600 ms: spaced that way, requests never run out before the window ends. It is not the wait after a 429.

With a queue, projected usage is (used + queued) ÷ limit × 100. Above 100%, the time shown is ceil((used + queued − limit) ÷ pace) seconds, how long the surplus takes at the average pace. Percentages are rounded to whole numbers and the pace to two decimals.

The tool has no clock and does not show a time until reset: take that from the API's reset header. The model is a single fixed window: token-bucket refill, sliding windows, burst allowances and per-endpoint limits are not simulated.

Related Tools

View all tools

Dev

HTTP Headers Viewer

See the request headers an echo service (httpbin.org) receives from one fetch by this page, or by your own URL. Copy as cURL, fetch(), Python or .env.

Dev

Latency Percentile Calculator

Paste latency samples in milliseconds for p50 to p99.9 by interpolation or nearest rank, plus mean, standard deviation and median-based outliers.

Dev

Lorem Ipsum Generator

Generate lorem ipsum placeholder text as paragraphs, sentences or words, up to 100 paragraphs or 5,000 words, with optional HTML paragraph tags.

Dev

HTML Minifier

Paste HTML to drop comments and collapse whitespace. The space between inline elements stays, pre and textarea are kept, and inline CSS and JS can be minified.

Dev

AES Encryption

Encrypt and decrypt text with a password using AES-256-GCM, the key derived by PBKDF2-SHA256 at 600,000 iterations. Strength depends on the password.

Dev

Chmod Calculator

Type a chmod mode such as 755 or 4755 to see rwxr-xr-x, or paste rwxr-xr-x or tick read, write and execute for owner, group and public to get the octal number.