English for Incident Post-Mortems: Blameless Language and Report Writing
Learn how to write blameless post-mortem reports in English with the right structure, vocabulary, and tone for professional incident analysis.
A post-mortem (also called an incident review or retrospective) is a structured document written after a system failure or significant incident. The goal is to understand what happened, why, and how to prevent recurrence — not to assign blame. Writing a good post-mortem in English requires both technical precision and careful attention to tone.
Post-Mortem Structure
Most organisations use a consistent structure. Understanding the purpose of each section helps you write them well.
| Section | Purpose |
|---|---|
| Summary | A brief overview of the incident, impact, and outcome |
| Timeline | A chronological log of what happened and when |
| Root cause | The underlying technical or process reason the incident occurred |
| Contributing factors | Conditions that made the incident more likely or more severe |
| Impact | Who was affected, for how long, and to what degree |
| Action items | Specific follow-up tasks with owners and due dates |
| Lessons learnt | Broader insights the team is taking away |
Timeline Vocabulary
Timelines use consistent, past-tense language. Common constructions:
- “At 14:32 UTC, the deployment was initiated.”
- “At 14:45 UTC, error rates on the payments API began to rise.”
- “At 15:10 UTC, the on-call engineer was paged.”
- “At 15:40 UTC, a rollback was completed and traffic returned to normal.”
Use UTC for all timestamps in post-mortems that are shared across teams or time zones.
Blameless Language
The blameless post-mortem is a principle pioneered at Google and widely adopted in modern engineering culture. The idea is that incidents are caused by systemic failures, not individual mistakes. The language you choose signals whether your post-mortem culture is truly blameless.
Blaming Language vs. Blameless Language
| Blaming | Blameless |
|---|---|
| ”The engineer deployed broken code." | "The deployment pipeline did not catch the regression before it reached production." |
| "The on-call failed to respond quickly." | "The alert threshold was set too high, delaying the initial response by 12 minutes." |
| "Someone forgot to update the runbook." | "The runbook had not been updated to reflect the new deployment process introduced in March.” |
The Passive Voice as a Blameless Tool
In blameless post-mortems, the passive voice is often deliberately used to shift focus from people to systems:
- “The configuration was not validated before deployment.” (not: “John didn’t validate the configuration.”)
- “The alert was not triggered because the threshold had not been updated.”
This is one of the few contexts in professional writing where passive voice is preferred over active voice.
Active vs. Passive Voice Choices
Outside of blameless framing, be deliberate about your choice:
- Use active voice in action items: “The platform team will add integration tests for this code path by 2026-05-01.”
- Use passive voice in timeline entries and root cause descriptions to maintain a systems focus.
Writing Action Items
Action items must be specific, owned, and time-bound. A vague action item is a promise that won’t be kept.
| Weak | Strong |
|---|---|
| ”Improve monitoring." | "Add an alert for error rates above 1% on the payments API. Owner: Ana. Due: 2026-04-30." |
| "Fix the deployment process." | "Update the deployment checklist to include a smoke test on the staging environment. Owner: Kai. Due: 2026-04-25.” |
Example Sentences
- “The root cause was a misconfigured environment variable that caused the service to connect to the production database during a load test.”
- “Contributing factors included the absence of a staging environment that mirrored production configuration.”
- “The incident resulted in approximately 1,200 users being unable to complete checkout for a period of 23 minutes.”
- “This action item will address the gap in our deployment pipeline by adding an automated rollback trigger when error rates exceed 2% within five minutes of a deployment.”
- “The lessons learnt section identified two systemic issues: insufficient observability and an on-call rotation that did not include engineers with knowledge of the payments service.”
Common Mistakes to Avoid
- Avoid “human error” as a root cause. It is almost never the root cause — it is a symptom of a process or system that allowed the error to have impact.
- Avoid vague contributing factors like “communication issues.” Instead, describe the specific communication gap: “The incident commander was not informed that the database migration had been delayed.”
- Write action items that are verifiable. If you cannot tell whether an action item is done, rewrite it.