Skip to main content

Chaos Engineering Checklist

Design a chaos experiment step by step. Fill in the hypothesis, select failure types, check off each phase, and generate a runbook to share with your team.

✓ Experiment builder form ✓ Interactive phase checklists ✓ Progress tracking ✓ Download runbook as .md
Overall Progress 0%

0 of 0 items checked

Experiment Builder

1

Pre-Experiment

Complete all steps before starting the experiment

0/7
2

Experiment Types

Select which failure modes will be tested

0/10
3

During Execution

Steps to follow while the experiment is running

0/4
4

Post-Experiment

Complete after the experiment ends

0/5
Share this tool: X / Twitter LinkedIn
✓ 60,000+ developers use DevPlaybook ★★★★★ 4.8 / 5 on Gumroad ✓ MIT licensed · Instant download ✓ No login required

Related Products

on Gumroad

You Might Also Need

More Free Tools

Enjoying this tool? Get more like it.

Weekly developer tool guides, productivity playbooks & AI tricks. Free. No spam.

DevPlaybook Pro 7 days free

Unlock AI-Powered Dev Tools

  • ⚡ AI Code Review, Doc Generator & SQL Builder
  • ⚡ All premium templates & early access
  • ⚡ Member discounts on Gumroad products
Start Free Trial →

$9/mo after trial · Cancel anytime

Want the full toolkit?

Get DevPlaybook Pro

Every template, guide, boilerplate, and automation script in one bundle. 13 premium products — grab them all at once and save big.

$79
$241 separately Save $162 (67% off)
Get DevPlaybook Pro — $79 →

MIT licensed · Instant download · No subscription

See what's included → Browse all deals →

Frequently Asked Questions

What is chaos engineering?▼

Chaos engineering is the discipline of experimenting on a system in order to build confidence in its ability to withstand turbulent and unexpected conditions in production. Pioneered at Netflix, it involves deliberately injecting failures (latency, service outages, resource exhaustion) to discover weaknesses before they cause real outages. The goal is to move from reactive incident response to proactive resilience building.

What is a steady state hypothesis?▼

A steady state hypothesis defines what 'normal' looks like for your system — a measurable output that shows the system is behaving correctly. Examples: '99th percentile API latency is under 200ms', 'checkout success rate is above 99.5%', 'error rate is below 0.1%'. Chaos experiments validate that this steady state is maintained even when failures are injected. If steady state breaks, you have found a real weakness.

What is blast radius?▼

Blast radius is the scope of impact if an experiment goes wrong. A full blast radius means the entire system is affected. Partial means a subset of traffic or nodes. Single-instance means only one pod or server. Best practice is to start with the smallest possible blast radius (single instance, canary traffic) and expand as you gain confidence. Always have a rollback plan that can return to steady state quickly.

When should I run chaos experiments in production?▼

Only run in production when you have: validated the experiment in staging, defined and measured your steady state baseline, set clear abort conditions, ensured monitoring and alerting are in place, notified on-call teams, and have a tested rollback plan ready. Start with a very small blast radius (single instance or 1% of traffic). Many organisations run chaos experiments during business hours when the full team is available to respond.

What tools are used for chaos engineering?▼

Popular chaos engineering tools include: LitmusChaos (Kubernetes-native, CNCF project), Chaos Monkey (Netflix, terminates random EC2 instances), Gremlin (SaaS platform, broad failure types), AWS Fault Injection Simulator (FIS), Chaos Mesh (Kubernetes), Pumba (Docker), and Toxiproxy (network-level latency/failure injection for integration tests). For game days and manual experiments, this checklist provides a structured approach without requiring any tooling.