A team wants to adopt chaos engineering after reading about it. What must be in place first, what is the correct progression, and what does chaos engineering not tell you?

The preconditions, which are the part usually skipped

Chaos engineering verifies resilience; it does not create it. Injecting failure into a system that has no redundancy, no timeouts and no circuit breakers produces an outage and a lesson everyone already knew.

Before starting, you need:

• Observability good enough to see the effect. If you cannot tell whether an experiment caused harm, you cannot run experiments — you are just causing outages with extra steps.
• A defined steady state: the metrics that say the system is healthy, with normal ranges. The experiment's hypothesis is stated against these.
• The resilience mechanisms actually implemented — retries, timeouts, breakers, fallbacks, redundancy.
• The ability to stop the experiment immediately, which must be tested before the first run.
• Organisational agreement, because the first experiment that causes visible impact will otherwise end the practice permanently.

The correct progression

1. Tabletop exercises. Walk through a failure verbally and find the gaps. Free, fast, and it consistently finds more than the first several real experiments do.
2. Game days in a non-production environment, with a scheduled failure, a hypothesis, and an assembled team.
3. Small production experiments during business hours — one instance, one dependency, a small percentage of traffic — with everyone watching and a rollback ready.
4. Larger, scheduled production experiments: a zone, a dependency, a region.
5. Automated continuous experiments, which is where the well-known tooling operates and is the end of the journey rather than the beginning.

Business hours, deliberately. Running experiments at 3am to minimise impact also means the people who understand the system are asleep, which inverts the purpose.

Every experiment has a hypothesis

"When we kill an instance in this service, the steady-state metrics remain within their normal ranges."

This framing matters because it makes the experiment falsifiable. A confirmed hypothesis is a genuine finding — you now have evidence rather than an assumption. A refuted one is a defect found under controlled conditions with the experts present, which is the cheapest possible way to find it.

What chaos engineering does not tell you

• Whether your system survives failures you did not think to inject. It tests the hypotheses you formed, and the next real outage will have a cause nobody enumerated.
• Anything about correlated failures, unless deliberately designed for. Real incidents rarely involve one clean component failure; they involve several things degrading in a way that is hard to construct.
• Whether your organisation can respond. That is what game days test, and it is a different exercise — the technical resilience and the human response are separate capabilities and only one of them is tested by automated fault injection.
• Anything about gradual degradation. Most tooling kills things; the more dangerous failure mode is a dependency slowing to 2 seconds rather than dying, and that must be injected specifically as latency, not as termination.
• Whether the fix works. A finding that is not remediated and re-tested is a documented weakness, not an improvement.

The honest positioning

Chaos engineering is a verification technique for organisations that have already invested in resilience. Adopting it as the first resilience investment is the common error, and it typically produces one dramatic incident followed by quiet abandonment.