API Rate Limit Calculator

The calculator assumes the rate-limit window only needs to absorb the users who are actually active at once, not your whole user base, so it divides the per-window ceiling by Max Concurrent Users and then scales that fair share by each user's typical requests-per-minute. If you set Max Concurrent Users lower than what actually shows up, the resulting per-user limit will be looser than intended, since the shared budget gets split among fewer imagined users.

Rate limit / window is the raw count of requests allowed inside one burst window — for example, a limit of 18,000 requests in a 60-second window. Throttle threshold (RPS) just converts that same number back into a steady per-second rate (300 RPS in this example) so it's easier to compare against your average and peak RPS figures or plug into gateway configs that expect a rate rather than a window count.

The safety margin is applied multiplicatively to peak RPS before the window limit is computed, so it exists purely to absorb burstiness the peak multiplier doesn't capture — short spikes above your modeled peak, clock-skew between distributed rate-limit counters, or retries piling up during a partial outage. If your traffic pattern is spiky rather than smoothly distributed across the burst window, a 20% margin is often too thin and pushes real users into 429s even though average and peak RPS look fine.

No — it's a stress-test figure, not a live measurement. It assumes traffic hits exactly 1.5x your calculated peak RPS and reports what fraction of that hypothetical overage would exceed the throttle threshold; it says nothing about how often real traffic actually reaches 1.5x peak. Use it to judge whether your safety margin gives you comfortable headroom, not as a forecast of actual 429 volume.