Blameless Incident Review
Learn from failures without blaming people.
The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.
[VERIFY] is an editorial flag, not a blank to fill. Wherever the prompt shows [VERIFY], check that item against a reliable source before you use it.
Facilitate a blameless review. The incident and timeline: [INCIDENT_AND_TIMELINE]. Impact: [IMPACT]. Actions taken during the incident: [ACTIONS]. People involved: [PEOPLE].
Produce: a neutral timeline (time, event, who knew what, decision made); contributing factors (conditions, signals, tools, processes, communication) listed without naming fault; questions that explore why decisions made sense at the time ("What did you see? What options did you consider?"); what went well; detection and response analysis (time to detect, time to respond, time to resolve, computed from the timeline); and corrective actions classified as prevent, detect, mitigate, with owners and dates.
Add ground rules, a facilitator script (80 words) for opening, and a summary for the wider organization (150 words). Include a check that actions are specific and tested. If the incident involved harm, legal, or privacy implications, involve the appropriate specialists [VERIFY].
Write contributing factors as conditions ('the alert threshold was set too high') rather than people's actions, and list questions to avoid because they imply blame, such as 'why did you not'. End with actions that have an owner and a date.
Fill in before use
Optional: type your details and the prompt above updates. Nothing is saved or sent.
Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.
See an example result (fictional data)
Incident: payment page down for 47 minutes on 12 March. Timeline: 14:02 deploy; 14:05 error rate rises; 14:09 alert fires (threshold too high); 14:20 engineer notices customer complaints; 14:38 rollback decided; 14:49 resolved. Time to detect: 4 minutes (errors from 14:05, alert at 14:09). Time to decide on rollback: 29 minutes after the alert. Total outage: 47 minutes from the 14:02 deploy to 14:49. Contributing factors: alert threshold set at 10 percent errors; deploy ran at peak time; rollback steps in an old document. What went well: customer support flagged it quickly. Why decisions made sense: the engineer first suspected the provider. Actions: lower alert threshold to 2 percent (owner Kim, 20 Mar); deploy freeze 14:00 to 16:00 (owner Ola); update runbook and test rollback (owner Raj, 27 Mar).
Illustrative only, made-up data. Your results will differ and must be reviewed.