Listening to Postmortem Review Calls: Language and Comprehension
5 exercises — identifying root cause statements, understanding contributing factor language, catching action item assignments, recognising blame vs systemic language, and following timeline narration in postmortem reviews.
0 / 5 completed
1 / 5
During a postmortem call, the facilitator says: 'The root cause was a memory leak in the connection pool introduced in the v2.4.1 deploy, which caused the API to become unresponsive after approximately 4 hours of elevated traffic.' Which statement is the ROOT CAUSE?
Root cause identification: In postmortem language, the root cause is the deepest technical reason the incident occurred — not the symptom (API unresponsive) or the trigger (elevated traffic). 'Memory leak in the connection pool introduced in v2.4.1' is the code change that created the vulnerability. Distinguishing root cause from contributing factors and symptoms is a key postmortem skill.
2 / 5
A postmortem facilitator says: 'Contributing factors included: our monitoring alert threshold was set too high and fired 45 minutes late, and the runbook for connection pool issues was outdated.' What is the difference between a ROOT CAUSE and a CONTRIBUTING FACTOR?
Contributing factors are conditions that amplified the impact or slowed the response — they did not directly cause the incident but made it harder to detect or recover. Here: the root cause was the memory leak; contributing factors were the delayed alert (slow detection) and outdated runbook (slow recovery). Both are important for prevention.
3 / 5
During a postmortem call, the incident commander says: 'Action items: DB-501 — Artem to patch the connection pool library by next Wednesday; OPS-112 — Lena to lower alert thresholds for memory usage to 70% by end of sprint; DOC-88 — Dmytro to update the runbook by Friday.' Who is responsible for updating the runbook?
Catching action item assignments: In postmortem calls, action items follow the pattern: 'Ticket — [Person] to [action] by [deadline].' Listen specifically for the name after the ticket ID. Dmytro is assigned DOC-88 (runbook update). Practise listening for name-task-deadline triplets in rapid-fire action item lists.
4 / 5
Which statement from a postmortem BEST reflects a blameless, systemic approach to incident analysis?
Blameless postmortem language: Effective postmortems focus on system failures, not individual errors. Option B identifies a process gap (no automated check for config drift) rather than blaming a person. Options A and C name or imply individuals. Option D focuses on human response speed rather than the system that required that speed.
5 / 5
A postmortem facilitator narrates the timeline: 'At 14:23 UTC, the deploy completed. At 14:45, memory usage began climbing. At 16:10, the alert fired. At 16:22, the on-call engineer acknowledged and began investigation. At 17:05, the fix was deployed and the service recovered.' What was the total incident duration from first symptom to recovery?
Timeline narration: The first symptom was at 14:45 (memory usage climbing). Recovery was at 17:05. Duration = 17:05 − 14:45 = 2 hours 20 minutes. Note: the deploy (14:23) was before the symptom — the incident clock starts at first symptom, not at deploy. Distinguishing 'deploy time', 'symptom start', 'alert time', and 'recovery time' is essential for calculating MTTD (mean time to detect) and MTTR (mean time to recover).