Chaos Scenario Generator
Create realistic API errors, HTTP failures, retry backoff scenarios, latency patterns, and timeout events. Useful for testing error handling, circuit breakers, and resilience patterns.
Also known as: failure scenario · error simulation · network chaos
seeded · synthetic data
Presets
Output
About this tool, tips & examples
What it does
The Chaos Scenario Generator produces realistic failure data for resilience testing: API error payloads, HTTP failure codes, retry/backoff sequences, latency spike patterns, and timeout events. Pick a scenario type, generate up to 1,000 events per run, and reuse a seed so a failing test case can be reproduced exactly.
Common use cases
- Chaos engineering — feed synthetic failure streams into consumers to observe how they degrade.
- Error-handling tests — table-driven tests over a varied set of API errors and HTTP failures instead of the same hand-written 500.
- Circuit breakers and retries — validate backoff logic against realistic retry timing sequences and mixed success/failure runs.
- Timeout and latency budgets — latency patterns with spikes and tail-heavy values for testing SLO alerts and client-side timeouts.
Settings
- Scenario type — API errors, HTTP failures, retry scenarios, or latency patterns; presets jump straight to each.
- How many — 1 to 1,000 events, exportable as text, JSON, or CSV for replay in your test harness.
- Seed — the same seed and settings reproduce the identical scenario — essential when a generated case exposes a real bug.
Privacy note
Scenarios are generated locally in your browser and never uploaded. All of it is synthetic test content — fabricated errors and timings, not real telemetry from any system.
FAQ
Why generate failures instead of writing them by hand? Hand-written fixtures encode your assumptions; generated ones surprise you. Variety in codes, messages, and timing is exactly what shakes out brittle error handling.
Can I reproduce the scenario that broke my test? Yes — that’s why the generator is seeded. Pin the seed in the failing test and the same event sequence comes back every run.
Does this actually inject faults into my system? No — it produces the data (payloads, codes, timings). Injection is up to your harness: serve the payloads from a mock, or drive delays from the latency values.