Postmortem Report · Example edition
Understand the failure. Improve the system.
This fictional incident concerns an outdated menu link during a café website update. Times and impact are sample values used to demonstrate a review structure.
| Time | Event | Evidence |
|---|---|---|
| 09:10 | Content update applied | Sample change record |
| 09:25 | Broken link reported | Sample support note |
| 09:40 | Previous link restored | Sample verification record |
| 10:00 | Follow-up owner assigned | Sample incident log |
02 / 04 · Postmortem Report
Impact and recovery
The menu link was unavailable for a thirty-minute example window. The team restored the previous destination and verified it on mobile. The number of affected visitors is unknown and should remain unknown until evidence exists.
Discussion prompt
Which part of this account needs stronger evidence?
03 / 04 · Postmortem Report
Contributing factors
The content checklist checked the visible menu label but did not test the destination after publication. The review process also lacked a named verifier for link changes.
Discussion prompt
What tradeoff should the audience understand?
04 / 04 · Postmortem Report
Follow-up work
Add a destination check to the content routine and assign a verifier for the next update. Review the revised process after two changes; avoid a long action list without owners or due dates.
Discussion prompt
Who owns the next action, and when will it be reviewed?