To replay a past incident, pick a well documented postmortem, assign roles from it to engineers, and walk through the decisions as they were made, with the original incident commander present if possible. Google calls its version the Wheel of Misfortune. It trains new responders on real events, not invented ones.
What the format is
Google's Workbook describes the practice: when training new engineers, a cast of engineers reenacts a previous postmortem, taking the roles laid out in it. The original incident commander attends to help make it as realistic as possible. The SRE book mentions the same exercise as a treat for new SREs.
It differs from a tabletop exercise mainly in source material. A tabletop usually starts from a scenario someone invents. A replay starts from something that really happened to you, so the systems, names and constraints are accurate.
Why use your own history
- The context is real. Responders recognise the tools and the ownership map.
- It gives old postmortems a second life. Google notes that reviewed postmortems are often months or years old.
- It checks the fix. After the replay, ask whether the same sequence could still happen.
- It teaches new joiners how your team decides under pressure.
Running a 60 minute security replay
| Time | Activity |
|---|---|
| 0 to 5 | Explain the rules: blameless, learning only |
| 5 to 10 | Assign roles: commander, scribe, communicator, responders |
| 10 to 40 | Walk the timeline in stages, revealing information as it was known then |
| 40 to 55 | Compare choices with the original, and note what is different today |
| 55 to 60 | Capture one change to the runbook or tooling |
Steps to prepare
- Choose a postmortem with a clear timeline and a closed set of actions.
- Remove the cause from the participants' view at the start. They should discover it as the responders did.
- Cut the timeline into four or five "injects", each a piece of new information such as an alert, a customer message or a log line.
- Keep a facilitator who knows the outcome and can answer questions in character.
- Invite the original commander as an adviser, not as a judge.
- Use only the redacted version of the document. Remove customer and personal data, as Google does for its internal write-ups.
What to watch for
- Hindsight. Participants who know the ending will want to skip steps. Ask them what they would do with only what was known at that time.
- Blame replay. If the exercise turns into mocking the original responders, stop and reset the rules.
- No follow-through. If you find a gap, file it like any postmortem action. See prevent, detect, mitigate: the three kinds of postmortem action.
How Safeguard fits
If your chosen incident was a vulnerable dependency, the replay can include a live "are we affected?" step. Safeguard's SBOM and dependency scanning supports that kind of lookup, with a free scan at https://gold.safeguard.sh/scan.
Quick check
Is a replay the same as a tabletop?
They overlap. A replay uses a real past incident as the script, which makes the details accurate and the lessons local.
Do we need the original incident commander?
Google's practice has them attend for realism. If they are not available, a facilitator who has read the write-up closely can stand in.
Sources
Last reviewed: 19 October 2026.
