Learn how to write and discuss post-incident reviews, post-mortems, and retrospectives in English — using blameless language, precise timelines, and constructive framing.
0 / 27 completed
1 / 27
What is the key principle of a 'blameless post-mortem'?
A blameless post-mortem focuses on what systemic conditions allowed the incident to happen — not which individual made a mistake. People make mistakes; the goal is to improve systems so the same mistake cannot happen again.
2 / 27
Which sentence uses blameless language correctly in a post-mortem?
Blameless language describes the system failure: 'the deployment pipeline did not prevent...' focuses on the systemic gap (missing validation) rather than individual blame.
3 / 27
What does 'contributing factor' mean in a post-mortem?
A contributing factor is a condition that made the incident worse or harder to resolve, without being the primary root cause. Example: 'Incomplete runbook documentation was a contributing factor that delayed the response.'
4 / 27
In a post-mortem timeline, which format is clearest?
Post-mortem timelines must use precise UTC timestamps, describe what was observed and by whom, and name the specific system or service affected. Vague times like 'around lunchtime' are useless across timezones.
5 / 27
What does 'MTTR' stand for and what does it measure?
MTTR (Mean Time To Recover or Resolve) measures how long it takes on average to restore service after an incident begins. A lower MTTR indicates a more resilient and well-practiced incident response process.
6 / 27
Which phrase best introduces the 'action items' section of a post-mortem?
'To prevent recurrence, we will:' is the standard professional framing. Action items should be specific, assigned to an owner, and have a target date. This phrase frames them as preventative, forward-looking commitments.
7 / 27
What is the difference between 'immediate mitigation' and 'long-term remediation' in a post-mortem?
Mitigation is the fast action taken during the incident to restore service (e.g. rollback, feature flag off, manual override). Remediation is the deeper fix that prevents the root cause from occurring again (e.g. automated config validation, improved monitoring).
8 / 27
Which sentence uses appropriate hedging in a root cause analysis?
Good root cause writing uses hedging ('we believe', 'based on the evidence') while citing specific evidence (metrics, timewindow). This is honest about the limits of the investigation without being uselessly vague.
9 / 27
What does 'five whys' mean as a post-mortem technique?
'Five whys' is a root cause analysis technique: you start with the symptom and ask 'why?' repeatedly (typically ~5 times) until you reach the underlying systemic cause. Developed by Toyota's Taiichi Ohno, widely used in SRE post-mortems.
10 / 27
What does 'incident severity' (SEV1–SEV5) describe?
Severity levels (SEV1–SEV5, or P1–P5) classify an incident by its impact and urgency. SEV1 typically means complete service outage or critical data loss; SEV5 is a minor cosmetic issue. Severity determines escalation, response team size, and communication frequency.
11 / 27
Sarah: "The build failed because the database connection timeout. It's John's fault for not setting the connection pool size correctly!"
As a senior developer reviewing Sarah's comment on the failing deployment, what is the most appropriate response to encourage constructive discussion and avoid assigning blame?
Sarah's comment is problematic because it immediately shifts blame without exploring contributing factors. The correct response acknowledges the problem (database connection timeout) but uses neutral language to describe the cause (connection pool size). This avoids directly accusing John and opens the door for a discussion about potential solutions instead of assigning fault. Option A is too harsh, option C lacks crucial detail, and option D actively promotes blame.
12 / 27
David: "The API returned a 500 error. It's Maria's fault for not implementing proper input validation!" As the tech lead reviewing David's comment on the failing API endpoint, which response best promotes a productive discussion and avoids direct blame?
David's response immediately assigns blame, which hinders learning. A constructive approach focuses on *understanding* what went wrong rather than pointing fingers. Framing it as resilience demonstrates a commitment to preventing future issues by investigating the underlying cause of the error and improving system design. Option C is therefore most appropriate – it encourages collaboration and prioritizes systemic improvements.
13 / 27
PR Description: "Fix: Resolved intermittent error with user authentication. Maria updated the JWT signing key. This was a critical issue impacting all users."
While acknowledging Maria's effort is fine, focusing solely on individual action without broader context can obscure systemic problems. A good PR description should still briefly mention the potential cause (JWT signing key) and invite discussion about whether more robust key rotation policies are needed to prevent future issues – this demonstrates a focus on preventing recurrence rather than simply celebrating a fix.
14 / 27
Sarah: "The build failed because the database connection timeout. It's John's fault for not setting the connection pool size correctly!"
As a senior developer reviewing Sarah's comment on the failing deployment, what is the most appropriate response to encourage constructive discussion and avoid assigning blame?
Sarah's comment is problematic because it immediately shifts blame without exploring contributing factors. The correct response acknowledges the problem (database connection timeout) but uses neutral language to describe the cause (connection pool size). This avoids directly accusing John and opens the door for a discussion about potential solutions instead of assigning fault. Option A is too harsh, option C lacks crucial detail, and option D actively promotes blame.
15 / 27
David: "The API returned a 500 error. It's Maria's fault for not implementing proper input validation!" As the tech lead reviewing David's comment on the failing API endpoint, which response best promotes a productive discussion and avoids direct blame?
David's response immediately assigns blame, which hinders learning. A constructive approach focuses on *understanding* what went wrong rather than pointing fingers. Framing it as resilience demonstrates a commitment to preventing future issues by investigating the underlying cause of the error and improving system design. Option C is therefore most appropriate – it encourages collaboration and prioritizes systemic improvements.
16 / 27
PR Description: "Fix: Resolved intermittent error with user authentication. Maria updated the JWT signing key. This was a critical issue impacting all users."
While acknowledging Maria's effort is fine, focusing solely on individual action without broader context can obscure systemic problems. A good PR description should still briefly mention the potential cause (JWT signing key) and invite discussion about whether more robust key rotation policies are needed to prevent future issues – this demonstrates a focus on preventing recurrence rather than simply celebrating a fix.
17 / 27
Sarah: "The build failed because the database connection timeout. It's John's fault for not setting the connection pool size correctly!"
As a senior developer reviewing Sarah's comment on the failing deployment, what is the most appropriate response to encourage constructive discussion and avoid assigning blame?
Sarah's comment is problematic because it immediately shifts blame without exploring contributing factors. The correct response acknowledges the problem (database connection timeout) but uses neutral language to describe the cause (connection pool size). This avoids directly accusing John and opens the door for a discussion about potential solutions instead of assigning fault. Option A is too harsh, option C lacks crucial detail, and option D actively promotes blame.
18 / 27
David: "The API returned a 500 error. It's Maria's fault for not implementing proper input validation!" As the tech lead reviewing David's comment on the failing API endpoint, which response best promotes a productive discussion and avoids direct blame?
David's response immediately assigns blame, which hinders learning. A constructive approach focuses on *understanding* what went wrong rather than pointing fingers. Framing it as resilience demonstrates a commitment to preventing future issues by investigating the underlying cause of the error and improving system design. Option C is therefore most appropriate – it encourages collaboration and prioritizes systemic improvements.
19 / 27
PR Description: "Fix: Resolved intermittent error with user authentication. Maria updated the JWT signing key. This was a critical issue impacting all users."
While acknowledging Maria's effort is fine, focusing solely on individual action without broader context can obscure systemic problems. A good PR description should still briefly mention the potential cause (JWT signing key) and invite discussion about whether more robust key rotation policies are needed to prevent future issues – this demonstrates a focus on preventing recurrence rather than simply celebrating a fix.
20 / 27
Sarah: "The build failed because the database connection timeout. It's John's fault for not setting the connection pool size correctly!"
As a senior developer reviewing Sarah's comment on the failing deployment, what is the most appropriate response to encourage constructive discussion and avoid assigning blame?
Sarah's comment is problematic because it immediately shifts blame without exploring contributing factors. The correct response acknowledges the problem (database connection timeout) but uses neutral language to describe the cause (connection pool size). This avoids directly accusing John and opens the door for a discussion about potential solutions instead of assigning fault. Option A is too harsh, option C lacks crucial detail, and option D actively promotes blame.
21 / 27
David: "The API returned a 500 error. It's Maria's fault for not implementing proper input validation!" As the tech lead reviewing David's comment on the failing API endpoint, which response best promotes a productive discussion and avoids direct blame?
David's response immediately assigns blame, which hinders learning. A constructive approach focuses on *understanding* what went wrong rather than pointing fingers. Framing it as resilience demonstrates a commitment to preventing future issues by investigating the underlying cause of the error and improving system design. Option C is therefore most appropriate – it encourages collaboration and prioritizes systemic improvements.
22 / 27
PR Description: "Fix: Resolved intermittent error with user authentication. Maria updated the JWT signing key. This was a critical issue impacting all users."
While acknowledging Maria's effort is fine, focusing solely on individual action without broader context can obscure systemic problems. A good PR description should still briefly mention the potential cause (JWT signing key) and invite discussion about whether more robust key rotation policies are needed to prevent future issues – this demonstrates a focus on preventing recurrence rather than simply celebrating a fix.
23 / 27
You're reviewing a Slack message from a junior developer regarding a recent outage. The message reads: 'The service went down because the database was slow. It's Sarah's fault for not scaling up the instance!'. As a senior engineer, what is the MOST appropriate response to encourage constructive discussion?
This question tests understanding of framing post-incident discussions. Option A focuses on immediate blame, while option B is unnecessarily confrontational and unproductive. Option C correctly emphasizes investigation and preventative action, shifting the focus from individual responsibility to systemic issues. Option D reinforces a blaming attitude.
24 / 27
During a post-incident review of a critical bug in a payment processing system, the team uses the 'Five Whys' technique. The initial problem identified is: 'The transaction failed'. What is the PRIMARY purpose of this method?
The 'Five Whys' technique isn't about assigning blame. It's a structured problem-solving method. While fixing the immediate issue is a positive outcome, the core purpose is to identify the *root cause*, which may be far more complex than simply 'the transaction failed'. Options A and B represent misinterpretations of the technique's intention.
25 / 27
A service incident report defines 'Incident Severity' as SEV1 - SEV5. Which statement BEST describes what SEV3 represents?
SEV3 signifies a 'major' incident. It indicates a significant impact – disrupting a large number of users and impacting critical business functions. SEV1 is too minor, SEV2 and SEV5 represent more severe levels of disruption. This question tests the understanding of standard incident severity classification.
26 / 27
During a standup meeting, a developer says: 'I was blocked on deploying the new feature because the CI/CD pipeline failed. It's David's fault for not updating the environment variables!'. As an engineering manager, what is the MOST appropriate follow-up question to ask?
This question tests communication skills in a post-incident context. Option A jumps to assigning blame and fixing without understanding the root cause. Option B encourages a detailed investigation into the *cause* of the failure, which is crucial for preventing recurrence. Options C and D are inappropriate responses that avoid problem-solving.
27 / 27
You receive an API response indicating a '429 Too Many Requests' error. The documentation states: "The API is rate limited to 60 requests per minute for all users." What does this primarily suggest?
A '429 Too Many Requests' error indicates an issue with *client-side* behavior. The rate limit documentation clearly states the constraint. It's highly likely that the user's application is exceeding this limit, triggering the response. Options A and D are incorrect assumptions; option B misinterprets the meaning of the HTTP status code.
What does the "Post-Incident Language" exercise practise?
Learn how to write and discuss post-incident reviews, post-mortems, and retrospectives in English — using blameless language, precise timelines, and constructive framing.
How many questions are in this exercise?
This exercise has 27 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Debugging Language category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Post-Incident Language" part of a larger series?
Yes — it's one exercise in the Debugging Language category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Debugging Language category page for related exercises, or browse the main Exercises hub for other IT English topics.