4 exercises — hand off an active incident between on-call engineers cleanly: state status, transfer ownership explicitly, and correct gaps as soon as you spot them.
0 / 14 completed
1 / 14
Your on-call shift is ending and the incident is still active. Which handoff message correctly transfers ownership to the next engineer?
A complete incident handoff states: (1) the severity and symptom, (2) the new owner by name, (3) current status, (4) the next concrete step, and (5) a link to shared context (war room, dashboard).
Formula: "Handing off [SEV] ([symptom]) to [name]. Status: [current state]. Next step: [action]. [Link to context]."
An incomplete handoff forces the incoming engineer to re-investigate from scratch, wasting minutes that matter during an active incident — and increasing the risk that the "next step" never actually gets executed.
2 / 14
You are the incoming on-call engineer receiving a handoff. What is the correct way to confirm you've taken ownership?
Accepting a handoff requires an explicit acknowledgement of ownership, not just a passive "okay" — and should restate the immediate next action to confirm shared understanding.
Formula: "Acknowledged — I have ownership of [incident]. I'll [next action] and post an update in [time]."
Explicit acknowledgement prevents the dangerous gap where both engineers believe the other still owns the incident — a common cause of dropped incidents during shift changes.
3 / 14
A handoff happens mid-incident but the outgoing engineer forgot to mention that they already tried restarting the affected service (it didn't help). What is the correct follow-up once this gap is discovered?
If you realise after a handoff that you omitted important information, send an explicit correction message as soon as possible — don't assume it will surface naturally or wait for the post-mortem.
Formula: "Correction to the handoff: I already tried [action] at [time] — it [result]. Flagging so you don't repeat it."
Handoffs are inherently lossy; proactively correcting gaps as soon as you notice them is a mark of a mature incident responder, and it directly saves the new owner's time.
4 / 14
The incident is resolved but happened right at your shift-change boundary. What is the correct way to communicate the final handoff?
Even a resolved incident deserves a closing handoff message so the next on-call has visibility into recent history — this matters if related symptoms recur on their shift. State clearly that no action is required so they don't waste time investigating a closed incident.
Formula: "Incident resolved at [time] before handoff — no ongoing action required. @[next], flagging for visibility. Post-mortem [status]. [Link]."
This closes the loop cleanly and gives the next on-call the context to recognise "oh, this is related to what happened last night" if a similar symptom reappears.
5 / 14
John, the senior engineer, is wrapping up his on-call shift and passing the incident (a high-severity database connection error) to Sarah. Which of the following Slack messages best facilitates this handoff?
The best option clearly states the incident details and offers support to Sarah. Options A is too vague, B lacks crucial information (severity), and C is overly terse and doesn't invite collaboration. D incorrectly frames the issue as transient, potentially masking a deeper problem.
6 / 14
David receives a handoff notification for an incident involving a failing API endpoint. After reviewing the initial report, he needs to confirm his understanding. Which of the following responses is most appropriate in a PR comment?
Asking for clarification demonstrates David's commitment to understanding the problem fully before taking action. Options A is too dismissive, B shows proactive investigation, and C suggests bypassing standard procedures. D simply acknowledges receipt without seeking necessary information.
7 / 14
Maria is investigating an incident where a microservice experienced intermittent downtime. The outgoing engineer briefly mentioned a recent code deployment but didn't provide details. After further investigation, Maria discovers the deployment introduced a bug that triggered the downtime. What's the most effective way for Maria to communicate this gap in information?
Maria should directly ask for clarification regarding the recent deployment. This is crucial for understanding the root cause and preventing similar issues in the future. Options A deflects responsibility, B ignores the critical information, and C suggests a temporary fix without investigation.
8 / 14
Ben is completing his shift after resolving an incident involving a queue backlog. He needs to inform the next on-call engineer. What is the MOST effective way for Ben to communicate this final handoff during a standup update?
Providing specific details about the resolution (confirmed no further impact and cleared logs) demonstrates thoroughness and provides valuable context for the incoming engineer. Options A is too brief, B lacks important verification steps, and C is unprofessional.
9 / 14
Emily receives a notification about an ongoing incident – a failing database query impacting user authentication. The initial report includes the following API response: `HTTP 500 Internal Server Error - Query Timeout`. What is the MOST appropriate follow-up message to send to the original reporter?
This response directly references the specific API response and explains the observed problem. It avoids jargon and clearly communicates the current status of the investigation. Options A is unhelpful, B provides a technical explanation without context, and C prematurely declares resolution.
10 / 14
John, the senior engineer, is wrapping up his on-call shift and passing the incident (a high-severity database connection error) to Sarah. Which of the following Slack messages best facilitates this handoff?
The best option clearly states the incident details and offers support to Sarah. Options A is too vague, B lacks crucial information (severity), and C is overly terse and doesn't invite collaboration. D incorrectly frames the issue as transient, potentially masking a deeper problem.
11 / 14
David receives a handoff notification for an incident involving a failing API endpoint. After reviewing the initial report, he needs to confirm his understanding. Which of the following responses is most appropriate in a PR comment?
Asking for clarification demonstrates David's commitment to understanding the problem fully before taking action. Options A is too dismissive, B shows proactive investigation, and C suggests bypassing standard procedures. D simply acknowledges receipt without seeking necessary information.
12 / 14
Maria is investigating an incident where a microservice experienced intermittent downtime. The outgoing engineer briefly mentioned a recent code deployment but didn't provide details. After further investigation, Maria discovers the deployment introduced a bug that triggered the downtime. What's the most effective way for Maria to communicate this gap in information?
Maria should directly ask for clarification regarding the recent deployment. This is crucial for understanding the root cause and preventing similar issues in the future. Options A deflects responsibility, B ignores the critical information, and C suggests a temporary fix without investigation.
13 / 14
Ben is completing his shift after resolving an incident involving a queue backlog. He needs to inform the next on-call engineer. What is the MOST effective way for Ben to communicate this final handoff during a standup update?
Providing specific details about the resolution (confirmed no further impact and cleared logs) demonstrates thoroughness and provides valuable context for the incoming engineer. Options A is too brief, B lacks important verification steps, and C is unprofessional.
14 / 14
Emily receives a notification about an ongoing incident – a failing database query impacting user authentication. The initial report includes the following API response: `HTTP 500 Internal Server Error - Query Timeout`. What is the MOST appropriate follow-up message to send to the original reporter?
This response directly references the specific API response and explains the observed problem. It avoids jargon and clearly communicates the current status of the investigation. Options A is unhelpful, B provides a technical explanation without context, and C prematurely declares resolution.
What will I practise in "Incident Handoff Communication — Incident Response English Exercise"?
Practise handing off an ongoing incident between on-call engineers: ownership transfer, acknowledgement, corrections, and closing handoffs. 4 exercises.
How many exercises are in this module?
This module has 14 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.