Chaos Engineering Game Day Plan and Report
Plan and document a chaos engineering game day with clear objectives, injected failures, observed outcomes, and follow-up action items. Use it to test resilience, capture what broke, and assign fixes before the next exercise.
Trusted by frontline teams 15 years of frontline software AI customization in seconds
Built for: Saas · Fintech · E Commerce · Healthcare Technology · Infrastructure And Cloud Services
Overview
This template documents a chaos engineering game day from planning through follow-up. It gives you a place to define the objective, scope, participants, injected failures, expected behavior, observed results, blockers, decisions, and action items with owners and due dates. The report format is useful when you need a shared record of what was intentionally broken, how the system behaved, and what should change before the next exercise.
Use it for controlled resilience testing on production-like systems, staging environments with realistic dependencies, or limited-scope production experiments where the team has agreed on guardrails. It is especially helpful when multiple teams are involved and you need a single source of truth for context, outcome, and next time. The structure also makes it easier to compare one game day to another and see whether remediation work actually reduced risk.
Do not use this template for routine incident notes, vague brainstorming, or broad architecture reviews. It is not a substitute for an incident postmortem, and it should not be used when the team has not agreed on rollback steps, monitoring, or ownership. If the exercise is too open-ended, the report becomes a list of observations without clear decisions or follow-up. The value of the template is that it turns a resilience experiment into a documented plan, a readable result, and a concrete action list.
Standards & compliance context
- Keep the exercise within approved change-management or operational-risk procedures if your organization requires formal authorization for production-impacting tests.
- Document the scope, timing, and rollback plan so the report can serve as evidence that the game day was controlled and intentional.
- Avoid recording sensitive customer data in the notes; capture service behavior and operational findings instead of raw payloads or secrets.
- If the exercise touches regulated systems, note any availability, logging, or incident-response obligations that were considered before the test.
General regulatory context for orientation only — verify current requirements with counsel or the relevant agency before relying on this template for compliance.
How to use this template
- 1. Fill in the game day objective, scope, environment, and success criteria before any failure is injected so everyone agrees on what the exercise is trying to prove.
- 2. List the participants, facilitator, note-taker, and service owners, then assign who will trigger each injected failure and who will monitor the system response.
- 3. Record each injected failure in order, including the start time, expected behavior, actual outcome, blockers, and any decision made during the exercise.
- 4. Capture action items as they arise with a named owner and due date, and separate immediate rollback tasks from longer-term resilience fixes.
- 5. Review the report after the game day, confirm which findings are accepted, and schedule the next time or follow-up exercise if the same gap needs retesting.
Best practices
- Write the objective as a testable statement, such as validating failover, alert quality, or recovery time, rather than a vague goal like improving resilience.
- Define the blast radius in plain language so every participant knows which service, region, or dependency is in scope and what is explicitly out of scope.
- Assign one person to facilitate and one person to capture notes so the report records decisions and outcomes instead of fragmented commentary.
- Log the exact injected failure and the system response in sequence, because the difference between expected and observed behavior is often the most useful finding.
- Attach action items to the specific gap they address, and include owner plus due date so remediation does not disappear after the exercise.
- Record blockers separately from outcomes so unresolved dependencies, missing permissions, or alert noise do not get mistaken for system behavior.
- Include a next-time section or follow-up note to show what should be retested after fixes are applied.
What this template typically catches
Issues teams running this template most often surface in practice:
Common use cases
Frequently asked questions
What is this template for?
This template is for planning and reporting a chaos engineering game day in one place. It captures the objective, scope, roles, injected failures, observed results, decisions, and action items. Use it when you want a repeatable record of what was tested and what needs to change afterward.
When should we run a chaos engineering game day?
Run it after a service has enough monitoring, alerting, and rollback capability to make the exercise safe. It is especially useful before major releases, after architecture changes, or when you want to validate a known failure mode. Avoid using it as a substitute for basic operational readiness.
Who should own this plan and report?
A reliability engineer, platform engineer, or incident lead usually owns the template, but the exercise should include service owners and on-call responders. The owner should define the agenda, coordinate the injected failures, and make sure action items have named owners and due dates. If the exercise spans multiple teams, assign one facilitator and one note-taker.
How is this different from ad-hoc chaos testing notes?
Ad-hoc notes often miss the context needed to turn findings into fixes. This template separates objectives, scope, injected failures, outcomes, blockers, and action items so the exercise can be reviewed later. That structure makes it easier to compare game days over time and see whether resilience improved.
What should be included in the scope section?
Include the service, environment, dependencies, and any explicit exclusions. State whether the exercise is limited to a single API, a region, a queue, or a downstream dependency. Clear scope prevents accidental impact outside the intended test area and helps reviewers understand the boundaries of the exercise.
What are common mistakes when using this template?
Common mistakes include vague objectives, no rollback plan, and action items without owners. Another frequent issue is recording only the failure injected, not the actual outcome and follow-up. The template works best when the report captures both the intended experiment and the real operational response.
Can this template be customized for different systems?
Yes. You can tailor the injected failures, success criteria, and action-item categories to match microservices, data pipelines, infrastructure, or third-party integrations. Keep the core structure intact so each game day still produces a comparable report.
Does this template help with compliance or audit needs?
It can support internal control evidence by showing that resilience testing was planned, executed, and followed up. If your organization has change-management or operational-risk requirements, keep the approval, scope, and remediation history in the report. It is not a legal control by itself, but it creates a useful record.
Related templates
Ready to use this template?
Get started with MangoApps and use Chaos Engineering Game Day Plan and Report with your team — pricing built for small business.
