What is the difference between token bucket and sliding window?

Token bucket (fixed window) resets the counter at the start of each window. Requests accumulate and can burst at the window boundary. Sliding window tracks requests within a rolling time frame, so the limit is spread more evenly and burst spikes are harder to exploit.

What does burst capacity mean?

Burst capacity is the maximum number of requests you can send in a short period. For token bucket, it equals the rate limit multiplied by the burst multiplier. A burst of 2× means you can fire twice the normal rate momentarily as long as the bucket has tokens.

Why add a safety buffer to sliding window?

APIs often apply limits with slight server-side clock skew or additional overhead. A 10% buffer means if the limit is 100 requests per minute, you target 90, leaving headroom for network jitter and ensuring you never hit the hard ceiling.

What is the safe polling interval?

The minimum time between requests to sustain traffic without exceeding the rate limit. It is calculated as window_duration / rate_limit in milliseconds. For GitHub's 5,000 req/hr that is 720ms per request.

How should I handle HTTP 429 Too Many Requests?

Implement exponential backoff starting at the Retry-After header value. Double the delay on each subsequent 429 and cap at a maximum (e.g., 60 seconds). This ensures you recover gracefully without hammering the server.

Do these formulas apply to streaming or WebSocket connections?

Token bucket and sliding window apply to discrete request counts. Streaming connections are typically limited by connection count or bandwidth, not per-request rate. Check the API documentation for connection-level limits separately.

Rate Limit Calculator

Enter your rate limit and window size to calculate safe request throughput, burst capacity, and minimum delays for token bucket or sliding window algorithms.

Rate Limit Parameters

Algorithm

Rate limit (requests)

Window duration (seconds)

Burst multiplier

1 = no burst; 2 = allow 2× rate momentarily

Load a common API limit

Enter parameters and click Calculate

Key Metrics

Request Rate Safety Table

Rate (req/s)	Requests / min	Status

Common API Rate Limits

API	Limit	Safe interval
GitHub REST API	5,000 req/hr	720 ms
Twitter/X API v2	300 req/15 min	3,000 ms
Stripe API	100 req/s	10 ms
OpenAI (Tier 1)	500 req/min	120 ms
Slack API	1 req/s per method	1,000 ms
Cloudflare API	1,200 req/5 min	250 ms

Summary

Enter your rate limit and window size to calculate safe request throughput, burst capacity, and minimum delays for token bucket or sliding window algorithms.

How it works

Choose an algorithm: Token Bucket / Fixed Window or Sliding Window / Leaky Bucket.
Enter the rate limit (number of requests allowed) and the window duration in seconds.
For Token Bucket, set the burst multiplier to allow short bursts above the sustained rate.
For Sliding Window, set a safety buffer percentage (default 10%) to stay below the hard limit.
Read the calculated throughput, delay, burst capacity, and the safe/risky/limit-trigger table.

Use cases

Calculate the safe polling interval before building a cron job that calls a third-party API.
Size a token bucket burst buffer when designing a gateway that proxies upstream API calls.
Verify that a batch processing pipeline stays within an external API quota over a 5-minute window.
Set the correct delay between retries when a client receives HTTP 429 Too Many Requests.
Compare GitHub, Stripe, or OpenAI limits against your expected request volume.
Debug rate limit breaches by checking actual throughput against the safe-request table.

Frequently Asked Questions

Last updated: 2026-09-22 · Reviewed by Nham Vu