English for Incident Post-Mortems: Blameless Language and Report Writing

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

1. “The root cause was a misconfigured environment variable that caused the service to connect to the production database during a load test.”
2. “Contributing factors included the absence of a staging environment that mirrored production configuration.”
3. “The incident resulted in approximately 1,200 users being unable to complete checkout for a period of 23 minutes.”
4. “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.”
5. “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.

Navigating Nuance: Specific Vocabulary for Incident Post-Mortems

Writing effective incident post-mortems is about more than just describing what happened. It’s about communicating clearly, fostering a culture of learning, and ensuring everyone understands the contributing factors – without assigning blame. For non-native English speakers, this can be particularly challenging due to subtle differences in phrasing and vocabulary that directly impact perception and understanding. Let’s focus on building your confidence with specific language choices frequently encountered in post-mortem reports and related communication.

One area where many developers struggle is differentiating between cause and effect. Simply stating “the code failed” isn’t sufficient. Instead, use phrases like “The root cause was identified as…” or “A contributing factor to the failure was…”. Notice the emphasis on identifying a cause, not merely observing an outcome. Similarly, when discussing timelines, precision matters immensely. Avoid vague terms like “a while back.” Opt for specific durations: “approximately 30 minutes,” “over two hours,” or “following the initial deployment.” Using temporal phrases accurately demonstrates your attention to detail and helps reconstruct the sequence of events effectively. Furthermore, the vocabulary around impact – “severity,” “scope,” “resolution” – is crucial. Saying “it was bad” doesn’t convey the same level of information as stating “the incident resulted in a service degradation affecting 15% of users.”

Beyond formal reports, consider how your communication influences the overall atmosphere. A common pitfall is using language that implies personal responsibility. Instead of saying “John didn’t test this properly,” which can feel accusatory, try “The testing process did not adequately cover the scenario leading to the failure.” This reframing shifts the focus from individual actions to system weaknesses and opportunities for improvement. Even in Slack messages discussing an incident, careful phrasing can make a huge difference. Instead of “This is your fault!”, consider “Let’s investigate what led to this unexpected behavior; perhaps we missed a key edge case during testing.” The goal is always collaborative problem-solving, not assigning blame.

Finally, remember that the language of post-mortems often incorporates technical terms, but it’s vital to ensure they are clearly defined for all stakeholders. Don’t assume everyone understands what “race condition” or “memory leak” means without explanation. Adding a brief definition alongside the term – especially in initial reports – demonstrates professionalism and facilitates shared understanding. Focus on communicating the impact of these technical issues, rather than getting bogged down in overly complex jargon.