Rate Limit Calculator
Convert an API rate limit into requests/second, /minute, /hour and /day, plan multi-worker throughput with staggered start offsets, budget a daily request quota, and turn a 429 Retry-After response into an exponential backoff schedule.
Input
How many requests the API allows per time unit. Leave at 0 to skip this section.
Multi-Worker Settings
Split the rate limit evenly across this many parallel workers/threads.
Daily Quota Planner (optional)
Total requests allowed per day. Leave at 0 to skip this section.
Hours per day your traffic actually flows (not idle/asleep).
Retry-After / Backoff Planner (optional)
Value from a 429 response's Retry-After header. Leave at 0 to skip this section.
How long you were sending requests before the 429.
Output
| Metric | Value |
|---|---|
| No data yet | |
| Metric | Value |
|---|---|
| No data yet | |
| Metric | Value |
|---|---|
| No data yet | |
| Metric | Value |
|---|---|
| No data yet | |
Guides
Almost every API enforces a rate limit — "300 requests per 15 minutes," "5,000 per hour," "100 per second" — and the headline number rarely tells you what you need: how fast you can safely send requests one at a time, how to split that budget across parallel workers, and what to do the moment you get a 429. This calculator answers all three, plus a daily-quota view for APIs billed by the day.
It runs four independent conversions. Fill in only the sections relevant to you — each is skipped if left blank or at 0.
How to use it
- Core rate calculations — enter the rate limit and its time unit (second/minute/hour/day). Get requests/second, /minute, /hour, /day, the minimum delay between requests, and a "safe" delay with a 10% buffer. For limits quoted above per-second, it also shows the burst capacity if you spend the whole allowance at once.
- Multi-worker throughput — set how many parallel workers (threads, processes, Lambda instances) share the limit. The tool splits the per-second rate evenly and gives each worker a staggered start offset so they don't all fire at once.
- Daily quota planner — for a total daily cap rather than a per-second one, enter the daily limit and how many hours a day traffic actually flows. It spreads the budget across those active hours plus a 10%-of-hourly burst allowance.
- Retry-After / backoff planner — after a 429, enter requests sent, the time window, and the
Retry-Aftervalue. The tool back-calculates the rate that tripped the limit and prints an exponential backoff schedule (doubling each attempt, capped at one hour) plus a jittered version (0–50% random padding) so retrying clients don't all collide.
Results recalculate as you type; every table is copyable and downloadable as CSV.
Rate limiting algorithms, quickly
- Token bucket — tokens refill at a fixed rate; each request spends one. Bursts are allowed up to the bucket size — roughly what "burst capacity" above estimates.
- Sliding window — counts requests in a rolling window. Smoothest, but memory-intensive server-side.
- Fixed window — resets a counter at fixed intervals. Simple, but allows a 2x burst at the window boundary.
Common headers
X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset describe the current window; Retry-After (on a 429) gives seconds to wait — feed that straight into the backoff planner above.
Why 10% buffers and jitter?
Network latency, clock drift, and rounding in the provider's limiter mean pacing at exactly the theoretical limit will eventually trip it. A small buffer trades a little throughput for far fewer 429s; jitter stops many clients from retrying in perfect unison.
Is this a token-bucket simulator?
No — it converts a stated rate limit into practical pacing numbers rather than simulating a bucket filling and draining live. The requests/second and burst-capacity figures are still the right numbers to design around even if your API's limiter is a token bucket internally.
This tool runs entirely in your browser — nothing you enter is sent anywhere.