Chaos Engineering in 2026: How to Start, Whether It Is Safe in Production, and What EU DORA Testing Requires

Most production incidents in a modern platform are not caused by one component dying cleanly. They come from a dependency that gets slow instead of failing, a retry storm that turns a blip into an outage, or a failover path that has never carried real traffic. Uptime Institute's 2026 outage analysis makes the same point at industry scale: Andy Lawrence, executive director of Uptime Intelligence, expects failures to be "linked to complex interactions between systems, including software, networks, and external dependencies" rather than single points of failure (Uptime Institute via ITWeb, May 2026). Design reviews and unit tests cannot find those interactions. Controlled experiments can. That is the job of chaos engineering, and below are the questions engineering leaders most often ask about it.

A network cabinet overflowing with tangled blue patch cables, a reminder that real systems fail through messy interactions rather than clean single faults. — Photo: Brian Hankins (Bhankins) / Public domain, via Wikimedia Commons

What is chaos engineering, really?

The canonical definition comes from the Principles of Chaos Engineering: it is "the discipline of experimenting on a system" to build confidence in its ability to withstand turbulent conditions in production. The key word is experimenting. Chaos engineering is not randomly killing servers to see what happens. Every experiment has four parts:

A steady state defined as measurable business output, not internal metrics. AWS gives the example of a payments system processing 300 transactions per second at a 99% success rate and 500 ms round-trip time (AWS Well-Architected, REL12-BP04).
A hypothesis stating which fault you inject, which mitigation should absorb it, and which metric proves it did. For example: if 20% of the nodes in a Kubernetes node group are terminated, the transaction API keeps p99 latency under 100 ms and alerts fire within three minutes.
A controlled injection with a defined scope, stop conditions and a rollback.
Verification and improvement: if steady state broke, fix the design and rerun the experiment.

If you already know the system will fall over, do not run the experiment. AWS is explicit that chaos engineering exists to find known-unknowns and unknown-unknowns; experimenting on something you know is broken teaches you nothing new. Fix it first.

How is chaos engineering different from load testing and DR testing?

The three are complementary, and teams that confuse them usually end up with a gap.

Load testing answers "how much can it take?" It finds capacity limits and bottlenecks under known traffic patterns.
Disaster recovery testing answers "can we get it back?" It validates failover, restore and your RTO and RPO targets for large, rare events such as losing a region.
Chaos engineering answers "what happens when one part degrades while everything else keeps running?" It targets partial failure: added latency, packet loss, a throttled dependency, a DNS failure, a killed pod during a deploy.

Partial failure is where the interesting bugs live. A May 2025 study of 971 GitHub repositories using ten chaos engineering tools found that network disruption (40.9%) and instance termination (32.7%) dominate the fault scenarios teams actually write, while application-level faults account for only 3.0% (Owotogbe et al., arXiv, 2025). That is a useful starting set, and also a hint at what most programmes under-test: what your own code does when a downstream call is slow rather than down.

Is chaos engineering safe to run in production?

It is safe when it is engineered to be, and the guardrails are well established. The Principles state that chaos "strongly prefers to experiment directly on production traffic", because staging rarely reproduces real request paths, data volumes and dependency behaviour. But nobody serious starts there. The progression that holds up in regulated environments:

Start in pre-production that resembles production, primarily to prove that your stop conditions trigger and your observability actually catches the fault.
Define stop conditions on customer-facing metrics. Error rate, latency percentiles and a synthetic user canary, wired to automatically halt and roll back the experiment. AWS Fault Injection Service supports up to five stop conditions per experiment template, tied to CloudWatch alarms.
Minimise the blast radius. One instance, one availability zone, one percent of traffic, or a canary deployment that runs a control and an experimental group side by side.
Run off-peak first, with people informed. Operations, SRE and customer support should know an experiment is running and have a channel to stop it.
Restore known-good state at the end, automatically where possible, and record the results.

The risk calculus is the real argument. You will experience a dependency timeout in production eventually. The only choice is whether it happens on a Tuesday at 10:00 with a rollback button and the right engineers watching, or at 03:00 during a release freeze.

How do you start chaos engineering?

Do not start with tooling. Start with your incident history. AWS lists "neglecting to use past post-incident analyses" as an explicit anti-pattern when choosing faults. A practical first quarter looks like this:

Pick one critical user journey with good observability and an SLO, ideally one that has caused a real incident.
List its resilience mechanisms (retries, timeouts, circuit breakers, multi-AZ, autoscaling) and the fault each one is meant to absorb. Rank faults by frequency and impact.
Run a facilitated game day for the highest-ranked fault: inject it, watch whether alerts fire, whether the runbook is right and whether on-call can diagnose it. Game days test people and process as much as code.
Turn passing experiments into regression tests. Once a hypothesis holds, AWS recommends automating it in the CI/CD pipeline so a later change cannot silently remove the mitigation. Not running experiments both in the pipeline and outside deployments is another anti-pattern on its list.

Which chaos engineering tools should you use?

On Kubernetes, the open-source CNCF projects Chaos Mesh and LitmusChaos are the default choices, and the GitHub study above found Chaos Mesh and LitmusChaos leading in ongoing development, with Toxiproxy and Chaos Mesh the most widely used overall. Toxiproxy is a lightweight way to inject network faults into integration tests. On AWS, Fault Injection Service covers EC2, ECS, EKS and RDS faults with native stop conditions, and can orchestrate Chaos Mesh and Litmus experiments. Azure offers Chaos Studio, and Gremlin is the main commercial platform. Whichever you pick, AWS discourages ad-hoc scripts unless they can read workload state, emit logs and roll back. Treat experiments as code, reviewed and versioned like everything else.

Does EU DORA require chaos engineering?

Not by name. But the Digital Operational Resilience Act creates obligations that a disciplined chaos programme satisfies well (Regulation (EU) 2022/2554):

Article 24 requires financial entities other than microenterprises to run a risk-based digital operational resilience testing programme, with tests performed by independent parties, a process to prioritise and remediate findings, and, at least yearly, appropriate tests of all ICT systems supporting critical or important functions.
Article 25 lists the test types the programme should provide for, including scenario-based tests and performance testing alongside scans and penetration tests. Hypothesis-driven fault injection is a scenario-based test with evidence attached.
Article 26 requires entities selected by their supervisor to run threat-led penetration testing at least every three years, performed on live production systems. If your organisation is in scope, the argument that experimenting in production is too risky has already been settled by the regulator.

What auditors want is evidence: the hypothesis, the scope, the result, the finding and the fix, plus proof the fix was retested. Chaos experiments captured as code, with logged results, produce exactly that trail.

Where to start

Choose one critical journey, write three hypotheses from your last three incidents, prove your stop conditions in pre-production, and run the first game day within a month. Then automate whatever passes. Resilience you have measured under controlled failure is worth far more, to your customers and your supervisor, than resilience you have only designed.