🪟Rate Limit Window Calculator

Fixed and sliding window maximums

req
s
rps
AspectFixed windowSliding window

The double pass at a fixed window boundary follows from the counter resetting each window. Predicting when a quota runs out belongs to the API rate limit time tool, and handling bursts with tokens belongs to the token bucket calculator, so neither is covered here.

You Might Also Need

How to use this rate limit window calculator

Enter the requests allowed per window and the window length, and the tool shows the maximum that passes under a fixed window and a sliding window, the sustained allowance and the minimum spacing between requests. Enter a client send rate and it also counts how many requests a single window rejects.

How the numbers are derived

The sustained allowance is the limit divided by the window length, and the minimum spacing is its reciprocal. The boundary maximum for a fixed window is twice the limit: with a limit of 100 per 60 seconds, up to 200 requests pass within a 60 second span, and that is the core difference between the two styles.

Limits and cautions

Which style a server uses is stated in its own documentation, and approximate implementations such as a sliding window counter give slightly different figures. Quota exhaustion timing and token bucket sizing belong to other tools.

Frequently asked questions

How do fixed and sliding windows differ?

A fixed window resets its counter each window, so a span across the boundary passes twice the limit. A sliding window keeps looking back over the trailing span, so that burst cannot happen.

Why does twice the limit get through?

Sending the full limit at the end of one window and the full limit again right after it rolls over puts both batches inside a span shorter than the window length.

Is sliding always better?

It stops the burst, but it has to keep timestamps or a weighted counter, which raises memory and implementation cost. Choose by the traffic you actually see.