Postmortem Writing Phrases
25 phrases for writing incident postmortems — the summary, a factual timeline, root cause analysis, blameless language, and clear, owned action items.
- Postmortems are blameless by convention — focus on "what made this possible," not "who did it".
- Timeline entries are always timestamped and factual — no interpretation, just what happened when.
- Separate the direct cause from the root cause — the trigger vs. the systemic weakness behind it.
- Every action item needs an owner and a due date — an unowned action item quietly never happens.
Writing the Summary
- On [date], [service] experienced [X] minutes of downtime, affecting [scope].Standard opening line — facts first, no blame
- The root cause was [X], triggered by [Y].Separates the underlying cause from what set it off
- Customer impact was limited to [scope] — no data loss occurred.Explicitly states what was NOT affected, not just what was
- This was a [severity level] incident, resolved within our SLA.Frames the incident against an existing standard
- The issue was detected by [alerting system / customer report] at [time].Documents how the incident was first noticed
Documenting the Timeline
- At 14:03 UTC, [event] occurred.Timeline entries are factual, timestamped, and blame-free
- At 14:12, on-call was paged and began investigating.Documents response time as a distinct fact
- At 14:20, the team identified [X] as the likely cause."Likely" is honest phrasing before full confirmation
- A mitigation was applied at 14:35, and the error rate began recovering.Distinguishes "mitigated" from "root cause fixed"
- The incident was declared resolved at 15:02.A specific, agreed-upon moment, not a vague "things got better"
Root Cause Analysis
- The direct cause was [X]; the underlying contributing factor was [Y].Separates the trigger from the systemic weakness behind it
- Using the "five whys" approach, we traced this back to [root cause].Names the analysis method used, for credibility
- This is the second time [class of issue] has caused an incident — see [previous postmortem].Flags a recurring pattern rather than treating it as isolated
- Our monitoring did not catch this early enough because [gap].Honest about detection gaps, not just the fix itself
- No single factor was sufficient on its own — this required [X] AND [Y] to happen together.Common, honest framing for genuinely complex failures
Blameless Language
- The deploy process allowed this change to reach production without [safeguard].Focuses on the process gap, not the person who deployed
- Anyone on the team could have made the same call given the information available at the time.Standard blameless-postmortem framing
- We're not asking "who," we're asking "what made this possible."Explicitly reframes the investigation's focus
- The engineer followed the documented runbook — the runbook itself was the gap.Redirects responsibility to documentation, not the individual
- This wasn't a mistake so much as a system that made the mistake easy to make.A common, respectful framing for human-error-adjacent incidents
Action Items & Follow-up
- Action item: add an alert for [condition], owner: [name], due: [date].Standard action-item format — specific, owned, dated
- This is a short-term mitigation; the long-term fix is tracked in [ticket].Distinguishes a quick patch from the real structural fix
- We're prioritising this above regular roadmap work given the severity.Signals urgency explicitly to stakeholders
- We'll revisit this postmortem in [X weeks] to confirm the action items were completed.Closes the loop instead of letting action items go stale
- Thanks to everyone who jumped in during the incident — the response itself went smoothly.Genuine, common way to acknowledge the response effort separately from the root cause
Frequently Asked Questions
What's the difference between 'root cause analysis' and '5 Whys' in a postmortem?
'Root cause analysis' is a broader methodology focusing on identifying the fundamental reason for an incident, often using techniques like Fishbone diagrams. '5 Why's' are a simpler technique where you repeatedly ask 'why' to drill down into potential causes. Root Cause Analysis can be more formalized and comprehensive while 5 Whys is quick and easy for initial investigation.
I'm documenting a bug related to a race condition. What's the correct terminology?
A race condition occurs when multiple threads or processes access and modify shared data concurrently, leading to unpredictable results. The appropriate term is 'concurrent modification of shared resources,' emphasizing the problem lies in how different parts of the code interact simultaneously.
When should I use 'lessons learned' versus 'action items'?
'Lessons Learned' focuses on broader systemic improvements – what needs to change across teams or processes based on the incident. 'Action Items,' conversely, are specific, actionable tasks assigned to individuals to address immediate problems identified during the postmortem.
How do I properly document a 'near miss' in a postmortem?
A 'near miss' represents an event that didn't result in harm but had the potential to. Documenting it should focus on what *could* have gone wrong, highlighting vulnerabilities and areas requiring attention—not dwelling on blame or the failure itself.
What does 'blast radius' refer to in a postmortem context?
'Blast Radius' describes the scope of impact an incident can cause. It refers to all the systems, data, users, or processes that could be affected if the initial problem isn't contained quickly – essentially, the ripple effect.
I need to describe a scenario where a deployment caused downtime. What's the best phrase?
Using 'unplanned outage,' is most appropriate when downtime occurred due to an unexpected event like a failed deployment or system issue, differentiating it from scheduled maintenance.
What's meant by 'technical debt' in relation to postmortems?
'Technical Debt' represents the implicit cost of rework caused by choosing an easy solution now instead of a better approach that would take longer. Postmortems can highlight technical debt contributing to incidents, such as outdated libraries or poorly documented code.
Explain the significance of 'time-to-detect' (TTD) in postmortem reporting.
'Time-to-Detect' (TTD) measures how long it took from when an incident started to when it was identified. A longer TTD indicates a failure in monitoring, alerting, or detection processes – crucial data for improving response times.
I'm documenting an issue with insufficient logging. What's the technical term?
'Inadequate Logging' refers to a lack of sufficient detail recorded by the system during an event, hindering effective troubleshooting and root cause identification – often a major contributor to incident complexity.
What is 'false positive' in the context of alerting systems during a postmortem?
'False Positives' are alerts that trigger without any actual underlying problem. Documenting these helps refine alerting rules, reducing alert fatigue and ensuring critical events aren't missed due to excessive noise.