Developer English guide
Writing an Incident Postmortem in English: Blameless Language That Works
October 21, 2026
Describing an outage factually, without turning the timeline into a list of who messed up, is a specific writing convention with its own vocabulary. Here is exactly how to write each section in English.
Key Takeaways
- A blameless postmortem describes what happened at a systems level, not who personally caused it: 'the deploy script did not validate the config,' not 'Juan forgot to check the config.'
- Every postmortem needs five sections: summary, timeline, impact, root cause, and action items.
- 'Mitigated' means the impact stopped. 'Resolved' means the root cause is actually fixed. They are not the same word.
- Names are fine in a timeline when they describe an action ('Maria deployed the hotfix at 14:32 UTC'), not when they frame the person as the cause of the failure.
- Action items need an owner and a date, same as any other action item, or they quietly disappear after the meeting.
Blameless is a writing convention, not just a feeling
'Blameless' es una convención de escritura, no solo una actitud
Most English-speaking tech companies write incident postmortems using a specific convention called 'blameless': the report describes what happened and why at a systems level, and deliberately avoids framing any one person as the cause.
This is not just a cultural nicety, it is a specific set of sentence patterns. The same event: a deploy that skipped a config check, can be written in a way that reads as an accusation or in a way that reads as a systems description. English-speaking teams expect the second one, and writing it correctly is a skill most developers are never explicitly taught.
This guide covers the structure every postmortem needs, the exact phrasing that keeps it blameless, and the vocabulary for describing severity, mitigation, and resolution.
The five sections every postmortem needs
Las cinco secciones que necesita todo postmortem
Different companies use different templates, but almost all of them map onto these five sections. Write them in this order.
Summary
One or two sentences: what broke, for how long, and who was affected.
Timeline
Timestamped events from detection to full resolution, in the order they happened.
Impact
Who and what was affected: users, requests, revenue, data, in concrete numbers if you have them.
Root cause
What actually triggered the incident at a systems level, not who triggered it.
Action items
Specific, owned, and dated changes that make this class of incident less likely or less severe.
Blaming phrasing vs. blameless phrasing
Frases que culpan vs. frases sin culpa
This is the core skill. The same fact can be written two ways: one names a person as the cause, the other names the system gap that allowed it to happen. Only the second one is standard in an English-language postmortem.
Juan forgot to check the config before deploying.
The deploy process did not include a config validation step.
The on-call engineer missed the alert.
The alert was not routed to a channel that was actively monitored at that hour.
Whoever wrote this migration didn't test it properly.
The migration was not tested against a production-sized dataset before release.
The reviewer should have caught this in the PR.
The code review process did not include a check for this class of error.
This happened because someone pushed straight to main.
A direct push to main bypassed the CI checks that would normally catch this.
The team ignored the warning signs last week.
The warning signs from last week were not escalated into an actionable alert.
Writing the timeline
Escribir la línea de tiempo
Timeline entries follow a fixed pattern: a timestamp in UTC, followed by a short, factual sentence in the past tense. Keep each line to one event. Here is a short example:
Notice the vocabulary: 'fired,' 'acknowledged,' 'rolled back,' 'mitigating,' 'resolved.' These are the standard verbs for an incident timeline in English.
Describing severity and impact
Describir la severidad y el impacto
Most companies use a Sev1 to Sev4 scale (sometimes P1 to P4). Pair the label with a plain-English description of the actual impact, not just the number.
| Sev1 / P1 | Full outage or a critical, customer-facing failure. |
| Sev2 / P2 | Significant but partial degradation: some users or some functionality affected. |
| Sev3 / P3 | Minor issue with limited impact, often caught before most users notice. |
| Sev4 / P4 | Cosmetic or very low-impact issue, usually fixed in a normal work cycle. |
Frequently asked questions
What does 'blameless postmortem' mean?
A blameless postmortem is the standard convention at most English-speaking tech companies for reviewing an incident: you describe what happened and why at a systems level, not who personally made the mistake. The assumption is that people act reasonably given the information and tools they had, so the fix is to improve the system (tests, alerts, process, documentation), not to single out a person.
Can I still mention who did what in a postmortem?
Yes, names are fine in the timeline when they are describing an action, not an accusation: 'Maria deployed the hotfix at 14:32 UTC' is neutral and useful. What you avoid is framing someone's action as the cause of the failure: the point is the system allowed that action to cause an outage, which is a process problem, not a people problem.
How do I describe the severity of an incident in English?
Most companies use a Sev1 to Sev4 (or P1 to P4) scale: Sev1 means a full outage or critical, customer-facing failure; Sev2 is a significant but partial degradation; Sev3 and Sev4 are smaller issues with limited impact. In prose, pair the severity label with a plain description: 'This was a Sev1: the checkout flow was fully unavailable for 23 minutes.'
What's the difference between 'mitigated' and 'resolved' in an incident report?
'Mitigated' means the immediate impact stopped, usually through a rollback, a feature flag, or a workaround, but the underlying cause may still be present. 'Resolved' means the actual root cause has been fixed. A timeline often has both: 'Mitigated at 14:40 UTC by rolling back the deploy. Resolved at 16:15 UTC once the config validation fix was merged.'
Ready to practice your English at work?
Lingua-e has interactive exercises built around real developer conversations: standups, code reviews, retrospectives, and more. Practice until it comes naturally.
Try Lingua-e for free
Written by
Roxana LafuenteLingua-e's founder
Roxana Lafuente is a software engineer with 8+ years of experience. At the beginning of her career, even though she had already passed the First Certificate in English, she still froze every time she had to speak up in the daily standup. That was a gap nobody was fixing. After 2,000+ standups, she figured out what actually builds fluency: practice that looks like your real work. She built Lingua-e so other developers wouldn't have to take the long road to feel confident working in an international development environment.