Practice the English vocabulary for blameless postmortems, incident reviews, and building a learning culture around system failures.
0 / 18 completed
1 / 18
What is a 'blameless postmortem'?
Blameless postmortems assume engineers act in good faith and make decisions with the information available at the time. The goal is to fix the system, not punish the person. This encourages honest reporting.
2 / 18
How would you rewrite this blame-based sentence in blameless language? 'John forgot to test the migration script on staging.'
Blameless language shifts from 'person made a mistake' to 'system/process had a gap'. The checklist framing identifies a concrete, fixable process improvement rather than attributing fault to an individual.
3 / 18
What does 'MTTR' stand for and why is it tracked?
MTTR measures incident response effectiveness. Teams track it alongside MTTD (detection) and MTTF (failure frequency). Improving MTTR might mean better runbooks, faster on-call paging, or more automation.
4 / 18
What is the purpose of 'contributing factors' in an incident review?
Contributing factors acknowledge that incidents are multi-causal. A missing test AND a deployment without monitoring AND an alert threshold too high all contributed — fixing only one does not fully prevent recurrence.
5 / 18
What does 'five whys' technique produce in an incident review?
Five whys drills down from symptom to root cause: Why did users see errors? → DB failover failed. Why? → No standby configured. Why? → Cost-cutting decision. Why approved? → No documented risk review process. Root cause: missing risk review gate.
6 / 18
What is an 'action item' in a postmortem and what makes it effective?
Effective action items are SMART: Specific (add smoke test), Measurable (to deployment pipeline), Assignable (Alex), time-bound (by next sprint). Vague actions like 'improve monitoring' rarely get done.
7 / 18
What does 'learning review' (used by some organizations instead of 'postmortem') emphasize?
Some organizations replace 'postmortem' (which implies death/failure) with 'learning review' to emphasize the positive outcome: knowledge gained. This framing reinforces that incidents are learning opportunities, not failures to be punished.
8 / 18
How would you facilitate a postmortem discussion to surface honest input?
Good postmortem facilitation creates psychological safety: set blameless norms explicitly, ask questions that assume good intent, and amplify quieter voices. Senior presence can suppress candid input if not managed.
9 / 18
Sarah from QA just posted this Slack message: 'David, you completely messed up the deployment! You didn't check the logs before pushing to production. This caused a major outage.' Which of the following best describes Sarah's approach and how it *could* be improved?
Sarah's message immediately focuses on blame ('you completely messed up'). This can shut down open discussion and discourage honest reporting. A better approach would focus on *what* happened and *why*, without assigning fault. The goal of an incident review is to understand the root cause and prevent recurrence, not to criticize individuals.
10 / 18
You're reviewing a pull request for a new feature that introduced a race condition. The PR description reads: 'Fixed the concurrency issue – Mark really needs to pay attention to this in the future.' What is the primary purpose of including this type of statement in a PR description, and what's wrong with it?
PR descriptions should focus on *technical* details – what was changed, why it was necessary, and any potential impact. Statements like 'Mark needs to pay attention' are subjective, potentially blaming, and don't contribute to learning. The goal is to provide context for reviewers and facilitate understanding of the code changes, not a personal critique.
11 / 18
During a standup meeting, Team Lead Alex says: 'Okay, David's incident with the database connection pool was his fault. He didn't follow the established procedures.' How does this statement relate to the concept of a 'learning culture'?
A learning culture emphasizes shared responsibility and systemic improvements. Alex's statement creates a blame-based environment, discouraging team members from openly sharing vulnerabilities or mistakes. Instead, focus should be on identifying *why* the procedure wasn't followed and how to prevent it in the future – a blameless approach is crucial.
12 / 18
An API response from a monitoring service indicates a spike in error rates for a critical microservice. The details include the following contributing factors: 'Increased user traffic,' 'Recent code deployment,' and 'Insufficient server capacity.' What is the *primary* value of documenting these 'contributing factors' during an incident review?
Identifying contributing factors isn't about assigning blame. It's about understanding the circumstances that led to the incident. These factors help determine if it was a technical problem (code), an operational one (capacity), or a combination of both – allowing for targeted solutions and preventative measures.
13 / 18
Your team is conducting a postmortem on a recent outage. After discussing the event, you realize that the root cause was a lack of proper monitoring for a specific database query. What does an 'action item' in this context aim to achieve?
An action item is a concrete step taken to address the root cause and prevent similar incidents. It's not just acknowledging the problem; it's outlining *what needs to be done* – for example, 'Implement automated monitoring of this query' or 'Update documentation on best practices.' A well-defined action item has clear ownership and a deadline.
14 / 18
Sarah from QA just posted this Slack message: 'David, you completely messed up the deployment! You didn't check the logs before pushing to production. This caused a major outage.' Which of the following best describes Sarah's approach and how it *could* be improved?
Sarah's message immediately focuses on blame ('you completely messed up'). This can shut down open discussion and discourage honest reporting. A better approach would focus on *what* happened and *why*, without assigning fault. The goal of an incident review is to understand the root cause and prevent recurrence, not to criticize individuals.
15 / 18
You're reviewing a pull request for a new feature that introduced a race condition. The PR description reads: 'Fixed the concurrency issue – Mark really needs to pay attention to this in the future.' What is the primary purpose of including this type of statement in a PR description, and what's wrong with it?
PR descriptions should focus on *technical* details – what was changed, why it was necessary, and any potential impact. Statements like 'Mark needs to pay attention' are subjective, potentially blaming, and don't contribute to learning. The goal is to provide context for reviewers and facilitate understanding of the code changes, not a personal critique.
16 / 18
During a standup meeting, Team Lead Alex says: 'Okay, David's incident with the database connection pool was his fault. He didn't follow the established procedures.' How does this statement relate to the concept of a 'learning culture'?
A learning culture emphasizes shared responsibility and systemic improvements. Alex's statement creates a blame-based environment, discouraging team members from openly sharing vulnerabilities or mistakes. Instead, focus should be on identifying *why* the procedure wasn't followed and how to prevent it in the future – a blameless approach is crucial.
17 / 18
An API response from a monitoring service indicates a spike in error rates for a critical microservice. The details include the following contributing factors: 'Increased user traffic,' 'Recent code deployment,' and 'Insufficient server capacity.' What is the *primary* value of documenting these 'contributing factors' during an incident review?
Identifying contributing factors isn't about assigning blame. It's about understanding the circumstances that led to the incident. These factors help determine if it was a technical problem (code), an operational one (capacity), or a combination of both – allowing for targeted solutions and preventative measures.
18 / 18
Your team is conducting a postmortem on a recent outage. After discussing the event, you realize that the root cause was a lack of proper monitoring for a specific database query. What does an 'action item' in this context aim to achieve?
An action item is a concrete step taken to address the root cause and prevent similar incidents. It's not just acknowledging the problem; it's outlining *what needs to be done* – for example, 'Implement automated monitoring of this query' or 'Update documentation on best practices.' A well-defined action item has clear ownership and a deadline.
What will I practise in "Incident Review and Learning Culture (English)"?
Practice the English vocabulary for blameless postmortems, incident reviews, and building a learning culture around system failures.
How many exercises are in this module?
This module has 18 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Incident Response exercises?
Browse the full Incident Response hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.