About the Rate Limit Calculator
This rate limit calculator turns any API quota — "600 requests per minute", "5,000 per hour", "100,000 per day" — into the same limit expressed per second, minute, hour, day and 30-day month. It then applies a safety margin and tells you how far apart to space requests, how many concurrent workers you need to actually reach that rate, and how long a batch job of a given size will take.
It is for backend developers writing API clients, data engineers planning a backfill or sync job, and anyone configuring a throttle, token bucket or queue worker pool. Use it before you start a long import so you know whether it finishes in minutes or days, and so you stay under the limit instead of collecting HTTP 429 "Too Many Requests" errors.
The worker estimate uses Little's law (concurrency = request rate × average response time) and assumes requests are spread evenly. Real APIs often count limits in fixed or sliding windows and may allow short bursts, so keep a margin of 10–20% and always honour the Retry-After and rate-limit headers the API returns.
With the default inputs, the limit in requests per second is 16.6667 req/s. Change any value above to recalculate instantly.
How to use the rate limit calculator
- 1Enter the request limit from the API documentation and pick its time window.
- 2Set a safety margin — 10–20% is a sensible buffer.
- 3Enter the average response time you see for one request.
- 4Enter how many requests your job needs to make.
- 5Read the per-second rate, the delay to put between calls, the workers needed and the total job time.
Formula and method
The limit is first normalised to requests per second by dividing by the window length in seconds (60 for a minute, 3,600 for an hour, 86,400 for a day, 2,592,000 for a 30-day month), and then multiplied back out to every other window. The safe target removes the safety margin you choose.
A single client that waits for each response can only send 1 ÷ latency requests per second. Little's law says the number of requests in flight equals arrival rate × time in system, so the workers needed to sustain the target is the target rate × the average response time in seconds, rounded up. The batch time is simply the number of requests divided by the target rate, assuming the API stays responsive and no requests fail.
- RPS
- Published limit converted to requests per second
- margin
- Safety margin as a fraction (10% = 0.10)
- latency
- Average response time in seconds
- workers
- Concurrent requests (threads, coroutines or connections) in flight
Worked examples
1,000 requests per minute with a 10% margin
1,000 ÷ 60 = 16.67 requests per second. Keeping 10% headroom gives a 15 req/s target, i.e. one request every 66.7 ms. At 250 ms per call, 15 × 0.25 = 3.75, so 4 concurrent workers are needed, and 100,000 requests take 100,000 ÷ 15 ≈ 6,667 seconds (about 1 h 51 min).
5,000 requests per hour, sequential client
A quota of 5,000 per hour is only 1.39 requests per second, or one every 720 ms. A single client taking 400 ms per call could go faster, so it must pause between calls. 20,000 requests need 20,000 ÷ 1.389 = 14,400 seconds — exactly 4 hours.
10 requests per second with slow responses
With a 20% margin the target is 8 req/s. Each request takes 1.2 s, so 8 × 1.2 = 9.6 requests must be in flight at once — round up to 10 workers. One million requests take 1,000,000 ÷ 8 = 125,000 seconds, almost 35 hours.
Frequently asked questions
How do I convert requests per minute to requests per second?+
Divide by 60. For example 600 requests per minute is 10 requests per second, and 1,000 per minute is about 16.67 per second. For per-hour limits divide by 3,600 and for per-day limits by 86,400.
What happens when I exceed an API rate limit?+
Most APIs reject the extra calls with HTTP status 429 Too Many Requests, often with a Retry-After header telling you how many seconds to wait. Repeated violations can lead to longer temporary blocks, so back off and retry with exponential delays.
How many concurrent requests do I need to hit a given rate?+
Multiply the target rate by the average response time in seconds (Little's law). At 20 req/s and 500 ms per request you need 20 × 0.5 = 10 requests in flight. If the API also caps concurrent connections, that cap may become the real limit.
What is the difference between a fixed window and a sliding window limit?+
A fixed window resets the counter at set times (for example every minute on the minute), so a client can send a full quota at 0:59 and another at 1:00. A sliding window or token bucket smooths this out, which is why spacing requests evenly is the safest strategy.
Why add a safety margin below the published limit?+
Your clock and the server's rarely align exactly, retries count against the quota, and other processes may share the same API key. Targeting 80–90% of the limit avoids sporadic 429 errors that slow a job down more than the margin does.