Chaos engineering is a disciplined experiment with a hypothesis, a limited blast radius and a way to stop, not random destruction. The common myths mostly come from the name. Here are seven, checked against the published principles and vendor guidance.
Myth 1: It means breaking things at random
Fact: The principles describe four steps: define steady state, form a hypothesis, introduce real-world variables, and try to disprove the hypothesis. Faults are prioritized by likely impact or frequency.
Myth 2: You must do it in production on day one
Fact: The principles prefer production traffic because it is the most reliable picture of real behavior, yet AWS recommends starting in non-production, checking that stop conditions work, and moving to production under controlled scope. Many teams begin with a staging game day.
Myth 3: It proves the system is reliable
Fact: It finds known-unknowns and unknown-unknowns. A passing experiment raises confidence in one hypothesis, nothing more.
Myth 4: Run it against a system you know is broken
Fact: AWS says not to. If you already know the workload will fail, fix it first. The experiment should be tolerated by the workload by default.
Myth 5: It is only about servers going down
Fact: The guidance lists latency, dropped packets, DNS failures, blocked third-party access, CPU and memory exhaustion, and traffic spikes as fault types. Slow is often worse than down.
Myth 6: It is a one-off event
Fact: The principles call for automating experiments to run continuously. AWS suggests that once a system survives an experiment, keep it as an automated regression test in the pipeline.
Myth 7: It is only for reliability teams, not security
Fact: Security controls fail too. Token validators, policy engines and log pipelines all have outage behavior that should be tested. The same method applies: pick a fault, state what should hold, and measure.
Where to start
Pick one control that matters, write a hypothesis, run it in a safe environment with a stop condition, and record what you learn. Our hypothesis and stop-condition posts walk through each part.
Quick check
Is a game day the same as chaos engineering?
They overlap. A game day exercises people and procedures with simulated events, and often uses fault injection. Chaos experiments can also run automatically with no people gathered.
Sources
- Principles of Chaos Engineering
- AWS Well-Architected REL12-BP04: Test resiliency using chaos engineering
- AWS Well-Architected REL12-BP05: Conduct game days regularly
Last reviewed: 19 October 2026.
