Set a refill rate and a burst size, describe the traffic — steady, with spikes, or a retry storm — and watch second by second how many requests pass and how many get a 429.
allowedrejected (429) — one bar per second
Runs entirely in your browser — nothing you enter here is sent to a server.
Picture a bucket that holds a fixed number of tokens. Tokens drip in at a steady rate until the bucket is full; anything beyond that overflows and is lost. Each request must take one token to proceed. If the bucket is empty, the request is rejected — usually with HTTP 429 — or made to wait.
Two settings define the behaviour. The refill rate is the long-run average you allow: 10 tokens per second means 600 requests a minute, sustained. The bucket size is the burst you tolerate: a client that has been idle can send that many requests at once before being slowed to the refill rate. This is what makes the token bucket friendlier than a fixed "N per second" limit — real clients are bursty, and a page load that fires 15 calls together should not be punished.
If steady demand exceeds the refill rate, the bucket empties and stays empty. Every request above the rate is rejected, whatever the burst size.
Legitimate bursts are cut off even though the client is well under its average allowance. The symptom is sporadic 429s for well-behaved users.
A client can hit the backend with a huge burst after a quiet period. Size the bucket to what the service behind it can absorb.
Rejected clients that retry immediately add load exactly when you are limiting. Always send Retry-After and expect clients to back off.
Start from capacity: the refill rate, summed over all clients, should not exceed what the service can handle. Then look at how clients really behave and set the bucket to cover a normal burst — often one to three seconds' worth of the rate. Use the simulator to check the edge cases before you ship the limit: what a dashboard refresh looks like, what happens when a batch job starts, how long a client stays blocked after a spike.
The rate is how fast tokens are added — the sustained requests per second you allow. The burst is the bucket's capacity — how many requests can be made at once after a quiet period.
A token bucket allows bursts up to its capacity and then limits to the refill rate. A leaky bucket releases requests at a constant rate, smoothing bursts out by queueing them. Token buckets suit APIs; leaky buckets suit traffic shaping.
Return HTTP 429 Too Many Requests with a Retry-After header saying when to try again. Do not queue indefinitely — a late answer is often worse than a clear rejection.
nginx's limit_req is a leaky-bucket variant: rate is the steady allowance and burst the number of excess requests it will queue or, with nodelay, pass immediately. The sizing logic is the same.
Upzilla checks your sites, servers and APIs around the clock and alerts you the moment something breaks. 10 monitors free, no card required.