Postmortem Writing Phrases — IT Phrasebook

The postmortem mindset, in English

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

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"

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

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 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