In preparing for rare incidents, the method tests response capability under controlled conditions. It shows where assumptions about stability, roles, and recovery are too optimistic.
DevOps Workshop method
Game Day
Rehearses controlled failure scenarios to check resilience, procedures, and team coordination.
Game Day examines resilience, operational procedures, and team coordination through controlled failure exercises. Observations show which safeguards and procedures work and where further improvements are needed.
Can the system and response team safely detect and handle this bounded failure scenario?
- Participants
- 5-20
- Time
- Halber Tag
Phases may be revisited; their order supports the work but does not replace domain judgment.

Objective
Choose objective and risk
Choose a critical service and learning goal; check blast radius and safe environment.
Boundaries
Prepare participants and stop controls
Inform responders, observers, and stakeholders; define kill switch and success signals.
Execution
Run the scenario under control
Inject the planned fault, observe system and response; stop if safety thresholds are breached.
Learning
Track learning
Restore normal state; capture observations, actions, owners, and next exercise date.
Review the result and open assumptions at the next suitable checkpoint. Record changes, ownership, and new evidence.
A good fit when
Use when: A recurring exercise program with an approved scenario, safety boundaries, and relevant operations roles.
Ideal for
- Resilience Testing
- Incident Preparedness
- Operations Training
Not good for
- Teams without baseline runbooks
- Unprepared live systems
Outputs

Working picture
Critical service, learning goal, blast radius, and a safe exercise environment.

Testable evidence
Planned fault, observed system behavior, and response within safety thresholds.

Next step
The exercise record documents restoration of normal operation, observations, actions, owners, and the next exercise date.
Safety-bounded scenario and exercise learning
Fictional worked example
Regularly rehearse controlled failure scenarios to check resilience, procedures, and team coordination.
Scenario
State learning goal, service, scenario, and environment.
Disable a read-only dependency in an isolated test environment.
Safety boundary
Define participants, observation, kill switch, and thresholds.
No production traffic; safety lead holds immediate kill switch.
Expected signals
Capture alerts, system state, and response during exercise.
Alert within 2 min; fallback active; no data changes; user impact <5 min.
Learning
Record recovery, findings, owners, and next exercise.
Fictional finding: dashboard omits dependency. Owner adds visibility; retest next quarter.
Fictional exercise: a read-only dependency fails in a production-like test environment. Goal: detect alert, activate fallback, keep user impact under 5 minutes. Safety lead can stop at any time. Exercise reveals a missing dashboard alert; no production traffic is injected.
First step
Start with a bounded question, clarify access and participants, and collect available evidence. Regularly rehearse controlled failure scenarios to check resilience, procedures, and team coordination.
Deep dive
A realistic scenario puts the system and the people involved under limited pressure so weaknesses become visible. What matters is less the perfect outcome than the behavior of the workflows under disruption. The insights improve readiness, coordination, and technical safeguards for the real case.
A Game Day tests readiness under controlled stress before a real outage tests the system. Realistic scenarios, observed roles, and deliberately protected environments make the difference. The value lies not in the spectacle but in visible gaps: missing runbooks, unclear responsibility, slow detection, or fragile recovery.
Before starting, scenario, safety boundaries, abort criteria, and observation points need the same clarity as a real operational exercise. The day becomes valuable where coordination, uncertainty, and recovery logic are taken just as seriously as technical restoration. End it with a few remediations, owners, and a date for the next drill.
The method guide walks execution through 4 phases, timing, 4 pitfalls, and clear stop criteria.
Open method guideYour perspective
Does this method help with your work?
Your feedback helps shape the next improvements to methodatlas.
Sources and topics
Game Day: WorksheetPrepare Game Day with a clear question, roles, and sources.markdown
game-day-working-template.md
Prepare Game Day with a clear question, roles, and sources.
Game Day: Worksheet
Question
To be confirmed
Desired outcome
To be confirmed
Scope
Plan the full method Time: Set according to scope and available evidence
Complete this worksheet on paper or in your own document during the work.
Preparation for this scope
Method setup
- Materials: Shared workspace, accessible sources, and a decision log.
- Roles: Exercise lead · safety lead · response team · observers
- Advance information: Clarify the question, timeframe, data access, roles, and known uncertainties in advance.
- Overall time needed: Recurring exercise; plan preparation, execution, recovery, and action review separately.
- Setup: Create a shared version. Label facts, assumptions, and decisions separately.
Prepare for the work steps
Objective: Choose objective and risk
- Resilience goal, service criticality, and risk
Boundaries: Prepare participants and stop controls
- Approved scenario, participants, and kill switch
Execution: Run the scenario under control
- Monitoring, observer log, and user-impact limit
Learning: Track learning
- Findings, remediations, and next exercise date
Safety-bounded scenario and exercise learning
Scenario
State learning goal, service, scenario, and environment.
...
Safety boundary
Define participants, observation, kill switch, and thresholds.
...
Expected signals
Capture alerts, system state, and response during exercise.
...
Learning
Record recovery, findings, owners, and next exercise.
...
Blank worksheet: start with a bounded question. Enter observed facts only, mark assumptions, and record open questions and sources.
Conduct game days regularly · AWS Well-Architected
Objective: Choose objective and risk
Expected artifact: Bounded, approved failure scenario
Bounded, approved failure scenario
Entry:
...
- Is the scenario approved and bounded?
Boundaries: Prepare participants and stop controls
Expected artifact: Participant, communications, and safety plan
Participant, communications, and safety plan
Entry:
...
- Can anyone stop the exercise?
Execution: Run the scenario under control
Expected artifact: Observed system and team response
Observed system and team response
Entry:
...
- Is real user protection maintained?
Learning: Track learning
Expected artifact: Tracked findings and retest plan
Tracked findings and retest plan
Entry:
...
- Do gaps feed procedures and the next exercise?
Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/game-day/run-sheet
Alternatives and neighbors
Fitting alternatives with decision guidance, followed by other related methods.

Instead of Game Day, when you want to analyze failure scenarios in advance without actually simulating the real event.

Moves incident response into a shared thread, connects alerts with commands, and keeps decisions traceable.

Arranges events, decisions, and delays chronologically and makes causes and lessons learned visible.

Examines an incident with a view to decisions, assumptions, and system factors, and records the resulting lessons.

Asks its way step by step to a controllable cause and stops only once an effective countermeasure is within reach.

Compares goal and actual course, identifies deviations, and records concrete learning steps.
Constraints and origin
Profile
- Method form
- Workshop method
- Participants
- 5-20
- Time
- Halber Tag
- Maturity
- Established
- Origin
- Praxisgemeinschaft


