How is this different from the mock API error generator?

That one gives you an error payload — the JSON body. This gives you the situation around it: when it broke, whether the work happened, and what the client should do. You often want both.

Why does it refuse to give me twenty scenarios?

Because there are nine distinct ones. Repeating them to reach a number would make the list look thorough while adding nothing.

Are these real failure modes?

Yes, and deliberately common ones. Every scenario here is a shape that appears repeatedly in production incident write-ups rather than an invented curiosity.

API Failure Scenario Generator

Most API tests check that a 200 works and a 400 is rejected. Almost no defect lives there. The failures that cost money happen in the middle: the request that times out after the server has already charged the card, the 500 that arrives after a partial write, the response that is truncated halfway through valid-looking JSON. This draws from a hand-written catalogue of those situations, and each one states plainly whether the same request may safely be sent again.

How many scenarios

There are 9 distinct API failure 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 API failure scenarios will appear here.

What this generator does

Produces situations, not payloads. The site already has a mock API error generator, which gives you the JSON body a client receives; that is a fixture. This gives you the case: what broke, at which point in the request lifecycle, whether the server-side effect already happened, and what the client is supposed to do. Every scenario is checked for self-consistency before it appears, so one that claims the work never happened cannot also sit in the phase where it did.

How to use this tool

Choose how many scenarios you want.
Optionally filter to the ones where a retry is safe, or the ones where it is not.
Draw, then copy the set into your test plan.
Use a seed if the same plan needs to be reproducible.

Understanding the controls

How many scenarios: There are nine distinct API scenarios. Ask for more and it says so rather than repeating them, because a padded list of duplicates is worse than a short honest one.
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

Writing the resilience section of a test plan for a payment or booking integration
Reviewing whether a retry policy is safe or merely optimistic
Onboarding an engineer to the failure modes of a service they have just inherited
Running a failure-mode workshop without needing an incident first
Deciding which failures deserve an alert and which deserve a reconciliation job

How this generator works

The scenarios are a hand-written catalogue rather than combinations of a template, which is why the list is finite and why each one carries a specific trap. Selection is a shuffle without replacement, so no scenario appears twice in a set. Before display, each scenario is re-read by a coherence checker: the phase must agree with whether a side effect happened, any HTTP status must be a real one, and every scenario must state an expected client behaviour.

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 therefore explicitly not cryptographically secure — useful for a test plan, never for anything that needs unpredictability.

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

Assumptions this tool makes

You are testing a client that calls an HTTP API over an unreliable network.
Retry safety is a property of the request, not the status code alone.

Limitations and good to know

This is a catalogue of common failures, not an exhaustive list. Your own system will have failure modes nobody else has.
It describes what should happen; it cannot tell you what your service actually does. That is what the test is for.
There is no code here. It produces the scenario, not the harness to inject it.
Nothing is stored between visits, so use a seed if a plan needs to be reproducible.

Common mistakes

Testing only clean failures: A refused connection is the easiest case and the least informative. The interesting scenarios are the ones where the client and the server disagree about what happened.
Assuming a 5xx means nothing happened: A 500 after a partial write is a real and common shape. The response says failure; the database says otherwise.
Retrying everything with the same policy: A timeout on a non-idempotent write is not the same as a 502 from a proxy, and treating them identically is how one payment becomes two.

Practical tips

Start with the work-already-happened filter. Those are the scenarios most test suites omit entirely.
Pair each scenario with the specific line of code that is supposed to handle it. If you cannot find one, that is the finding.
Keep the seeded set in the repository so the plan can be reviewed as a diff when it changes.

Privacy and your data

Everything is generated in your browser. No scenario, seed or copied text is sent anywhere, and nothing is stored between visits.

Frequently asked questions

How is this different from the mock API error generator?: That one gives you an error payload — the JSON body. This gives you the situation around it: when it broke, whether the work happened, and what the client should do. You often want both.
Why does it refuse to give me twenty scenarios?: Because there are nine distinct ones. Repeating them to reach a number would make the list look thorough while adding nothing.
Are these real failure modes?: Yes, and deliberately common ones. Every scenario here is a shape that appears repeatedly in production incident write-ups rather than an invented curiosity.