Why is silent throttling in here at all?

Because it is the one that gets missed. It produces no errors, so an error-rate alert never fires and the service looks healthy while everything queues.

Should I always honour Retry-After?

Yes, when it is present. It is the server telling you what it will accept. Your own backoff is a fallback for when the header is absent.

Is this the same as the retry backoff schedule generator?

No. That one computes a concrete schedule of delays. This one gives you the situations that schedule has to cope with.

Rate Limit Scenario Generator

A rate limit is easy to handle in the case everyone tests: a 429 with a Retry-After header saying exactly how long to wait. The trouble is the other cases. The 429 with no header at all. The header in HTTP-date form rather than seconds. The limit that is shared across every workload using the same key, so a background job starves the interactive traffic. The throttling that never returns an error and only makes everything slower, which a dashboard counting non-200s cannot see.

How many scenarios

There are 7 distinct rate limit scenarios — it will not repeat them to pad a list.

Seed (optional)

A word brings the same set back, for a test plan you can re-derive.

Narrow it down

Only ones that are safe to retry

Only ones where the work already happened

Your rate limit scenarios will appear here.

What this generator does

Produces the rate limiting situations a client has to survive, each with the behaviour expected of it. The point of the catalogue is that the recoverable case — a clear 429 with clear guidance — is the one everybody already handles, and the other six are where clients break. Each scenario is checked before display, including that a scenario filed as rate limiting carries a rate limiting status.

How to use this tool

Choose how many scenarios you want.
Filter if you only want the recoverable ones.
Draw, then copy them into your test plan or runbook.
Seed it if the same set needs to come back.

Understanding the controls

How many scenarios: Seven distinct rate limiting scenarios exist here. It will not repeat them to fill a longer list.
Narrow it down: Two filters that change what you are practising. Safe-to-retry-only gives the cases a retry policy handles; work-already-happened gives the cases it does not, which are the ones that cost money.
Seed: Any word makes the draw reproducible, so a test plan can be re-derived from the same seed months later. Leave it empty for a different set each time.

Common use cases

Checking a client handles both legal forms of Retry-After
Deciding whether backoff needs jitter before a shared limit turns into an outage
Working out whether an integration needs its own credential rather than a shared one
Writing alerts that catch silent throttling, which never raises an error
Reviewing whether scheduled jobs all fire on the same boundary

How this generator works

A hand-written catalogue, shuffled without replacement, with a coherence check before display. The check is slightly stricter for this family: a rate limit scenario may only carry status 429 or 200, because a rate limit that reports itself as a 500 is a different bug.

Randomness and fairness

Which scenarios you get is random. Without a seed the draw uses the browser's cryptographically secure generator; with a seed it uses a small deterministic generator, which is reproducible and so explicitly not cryptographically secure.

For how randomness is produced across the whole site, see how Generate Random works.

Assumptions this tool makes

The client can observe response status and headers.
Limits may be per key, per route or per tenant, and the client does not always know which.

Limitations and good to know

It describes client behaviour, not server design. How to set a limit is a different question from how to survive one.
The scenarios are common shapes, not a specification of any particular API. Read the provider's documentation for the real numbers.
No load generation here — this produces the cases, not the traffic.
Nothing is saved between visits, so seed it if you need the set again.

Common mistakes

Ignoring Retry-After in favour of your own backoff: The server's number is the only authoritative one in the exchange. Overriding it is how a client gets blocked rather than throttled.
Backoff without jitter: Every client that was rejected together returns together. The retry becomes the second outage.
Assuming a rate limit always announces itself: Silent throttling shows up as latency, not errors. An error-rate dashboard reports everything is fine.

Practical tips

Test the no-header case first — it is the one most clients get wrong.
Schedule recurring work away from the top of the minute, and spread it deliberately.
If one credential serves both batch and interactive traffic, treat that as the finding rather than tuning the backoff.

Privacy and your data

Everything runs in your browser. Nothing you type or copy is sent anywhere or stored between visits.

Frequently asked questions

Why is silent throttling in here at all?: Because it is the one that gets missed. It produces no errors, so an error-rate alert never fires and the service looks healthy while everything queues.
Should I always honour Retry-After?: Yes, when it is present. It is the server telling you what it will accept. Your own backoff is a fallback for when the header is absent.
Is this the same as the retry backoff schedule generator?: No. That one computes a concrete schedule of delays. This one gives you the situations that schedule has to cope with.