Burst Rate Calculator

Calculator

Responsive layout: three columns on large screens, two on small, one on mobile.

Units are converted to events/s internally.

Sustained rate

Refill rate (r). Example: 120 per minute.

Burst capacity

Bucket size (B): maximum tokens/events stored.

Initial tokens

Starting tokens (T₀). Use B for a full bucket.

Evaluation interval

Choose the window you care about, like 10 seconds.

Peak rate (optional)

Used to estimate how fast a full burst drains.

Safety margin

Conservative recommendation for production policies.

Display output unit

Changes how rates are shown in results.

Output is placed above this form after submission.

Formula Used

This calculator uses the token bucket model commonly applied to API rate limiting, job queues, and traffic shaping.

Allowed(t) = T₀ + r · t

Total events permitted over an interval t.

AvgRate(t) = Allowed(t) / t = r + T₀ / t

Average burst rate over that same interval.

Refill(empty→full) = B / r

Time to refill from empty to full capacity.

DrainTime(peak) = T₀ / (p − r)

Only when peak rate p exceeds r.

Notes: B is the burst capacity, r is the sustained refill rate, and T₀ is the starting tokens.

How to Use This Calculator

Enter your sustained rate: the long-run safe throughput.
Set burst capacity: how many extra events you can absorb.
Pick an evaluation interval that matches your SLO window.
Optionally add a peak rate to estimate burst drain time.
Choose a safety margin for more conservative recommendations.
Press Calculate, then export the results as CSV or PDF.

Example Data Table

Sample scenarios for quick validation.

Scenario	Sustained rate	Burst capacity	Initial tokens	Interval	Allowed events	Average over interval	Refill from empty
A	50.0000 per second	500	500	10.0000 seconds	1,000.00	100.0000 events/s	10.00 s
B	120.0000 per minute	300	150	30.0000 seconds	210	7.0000 events/s	150.00 s
C	5,000.00 per hour	2,000.00	2,000.00	5.0000 minutes	2,416.67	8.0556 events/s	1,440.00 s

Example A shows a short 10-second window with a full bucket. Example B demonstrates a lower refill rate with partial starting tokens. Example C uses hourly throughput with a longer interval.

Why burst rate matters for production limits

Burst allowance decides whether short spikes trigger throttling, retries, and user-visible latency. If a service sustains 50 events/s but receives 300 events/s for 2 seconds, a bucket with 500 tokens absorbs the shock while keeping the long-run policy intact.

Mapping real workloads to token bucket inputs

Use sustained rate for the steady budget your downstream can handle, then set burst capacity from observed concurrency. For example, a queue consumer at 1200 events/min equals 20 events/s. If deployments create a 10× surge, a 400-token bucket buys roughly 20 seconds of headroom at 40 events/s above baseline. Set initial tokens to capacity for full credit after idle.

Choosing an evaluation interval that matches SLOs

The interval should reflect how you measure pain. A 10-second window aligns with edge limits, while 60 seconds fits gateway policies. With r = 20 events/s and T₀ = 200 tokens, the maximum average over 10 seconds is 40 events/s, but over 60 seconds it falls to 23.33 events/s. This shows why long windows reward steadiness, not brief spikes.

Interpreting drain time and refill time

If you provide a peak rate p, the calculator estimates how long burst credit lasts: DrainTime = T₀/(p−r). With p = 100, r = 20, and T₀ = 200, you drain in 2.5 seconds. Refill time from empty is B/r; a 400-token bucket at 20 events/s refills in 20 seconds. Use these two numbers to choose cooldowns and backoff.

Sizing buffers for retries and jitter

Retries multiply load during incidents. A 5% retry rate on 20,000 daily requests adds 1,000 extra attempts, and clustered retries are worse than the average. Applying a 10% safety margin lowers the recommended sustained rate and increases burst capacity so brief storms do not immediately hit hard limits. Pair this with jittered retries to smooth demand.

Export-ready outputs for reviews and runbooks

Teams often need numbers for change requests and postmortems. Export CSV for spreadsheets, or PDF for tickets and runbooks, capturing inputs, allowed events per interval, and recommended settings. Keeping these artifacts near on-call docs speeds safe policy updates and audits. When policies change, re-run the calculator with new traffic data and attach the exports to the same pull request.

FAQs

Q1. What is burst rate in this calculator?

Burst rate is the highest short-window average throughput permitted by your token bucket: r + T₀/t. It differs from sustained rate, which limits long-run traffic. Use it to predict short spikes.

Q2. How do I pick burst capacity?

Start from your largest expected spike during the interval: extra ≈ (peak − r)·duration. Choose B at least that extra, then add margin. If you run multiple workers, include their combined concurrency.

Q3. What does initial tokens mean?

It is the starting credit. Set it to B for full burst credit after idle; set lower to simulate cold start or recently drained limits. It directly affects allowed events and short-window averages.

Q4. Why does the average rate change with interval?

Because burst credit is amortized: AvgRate(t)=r+T₀/t. As t grows, T₀/t shrinks, so the average approaches r. Longer windows penalize brief bursts and reward consistent flow.

Q5. What is drain time, and when is it infinite?

Drain time estimates how long tokens last at peak p: T₀/(p−r). If p ≤ r, the bucket does not drain in the ideal model because refill keeps up. Real systems may still throttle with discrete events.

Q6. How should I use the safety margin?

Use it to derate sustained rate and overprovision burst capacity for uncertainty: clock skew, retries, uneven balancing, and measurement error. Common starting points are 5–15%, then tune using observed p95/p99 throughput.