Write an incident postmortem and runbook
A blameless postmortem with timeline, root cause, actions, and a runbook update.
The prompt
Role: Act as an SRE writing a blameless incident post-mortem and the follow-up runbook.
Context: Incident summary and impact (who/what, duration, severity): [INCIDENT]. Timeline notes and signals: [TIMELINE_NOTES]. What was done to mitigate and resolve: [ACTIONS_TAKEN]. Suspected causes and contributing factors: [SUSPECTED_CAUSES]. Monitoring/alerting state at the time: [MONITORING_STATE].
Task: Produce: (1) a factual timeline (detection, diagnosis, mitigation, resolution) with timestamps; (2) the root cause and contributing factors, written without blaming individuals - focus on systems, process and information gaps; (3) what went well; (4) corrective actions with owner, priority and due date, split into 'prevent recurrence' and 'reduce impact / detect faster'; (5) a runbook for handling this class of incident next time.
Format: Sections: Summary & impact | Timeline | Root cause & contributing factors | What went well | Corrective actions (table) | Runbook. ~700 words.
Verification: Separate timeline facts from reconstruction; flag any timeline gap and any cause not yet confirmed.
Validation: Review the actions as a sceptical engineering manager: would completing them actually prevent or shorten a repeat, or are they busywork? Strengthen the weakest.
Highlighted [brackets] are blanks to replace with your own details.
Fill in the blanks and use this promptMore Software Development prompts
What to fill in
- INCIDENT
- TIMELINE_NOTES
- ACTIONS_TAKEN
- SUSPECTED_CAUSES
- MONITORING_STATE
How this prompt is built
This prompt follows the RCTFVV structure (Role, Context, Task, Format, Verification, Validation). RCTFVV extends RCTF with two checking steps. Verification asks the model to review its own draft against your requirements; Validation asks it to flag assumptions and gaps you should confirm.
Related prompts
- Write a README and publish my first coding project on GitHubA clear README, a safe publishing checklist, and a short post to share what you built.
- Write or review a network switch configuration changeA vendor-aware switch config for your requirement, plus a pre-change review, rollback steps, and verification commands.
- Write a security finding for a penetration test reportTurns your notes on a vulnerability into a clear, professional finding with risk rating, evidence, impact, and fix steps.
- Write a technical design doc (RFC) reviewers can approveTurns a rough technical plan into a structured RFC with alternatives, risks, and open questions reviewers can sign off on.