4 exercises — declare severity levels with concrete impact language, justify triage decisions against a severity matrix, and escalate cleanly when conditions worsen.
0 / 14 completed
1 / 14
You just noticed the checkout service is returning 500 errors for roughly 15% of requests. Which is the correct way to declare the incident and its severity?
A correct severity declaration names the severity level, states the observed impact in concrete terms (percentage, affected service), and claims a role (incident commander) so the response has an owner from the first message.
Declaration formula: "I'm declaring a [SEV-N] — [service] is [symptom] for [scope/impact]. I'm [taking/handing off] incident commander."
Why this matters: vague declarations ("something is wrong") waste the first, most valuable minutes of an incident. A specific declaration lets other engineers self-select into the response based on their expertise.
2 / 14
Your team's severity matrix defines SEV1 as "complete outage or data loss, all-hands" and SEV2 as "major functionality impaired for a significant user segment." A colleague asks why you triaged a partial checkout outage as SEV2, not SEV1. Which explanation correctly justifies the triage?
Correct triage language cites the specific criterion from the severity matrix that was or wasn't met, and commits to re-evaluating if conditions change. This is the core skill of severity triage: mapping an observed symptom to a defined threshold, not a gut feeling.
Useful phrases: "this meets the bar for…", "this doesn't yet meet the threshold for…", "I'll re-triage if [condition] happens", "escalating to SEV1 because [metric] crossed [threshold]".
Triage decisions should always be traceable to the written severity criteria — this prevents both over-declaring (crying wolf) and under-declaring (missing a real crisis).
3 / 14
Fifteen minutes into a SEV2, the error rate jumps from 15% to 60% and payments start failing entirely. Which is the correct way to communicate a severity escalation?
A severity escalation must state (1) the old and new severity, (2) the specific metric change that triggered it, and (3) the concrete next action (paging, opening a war room).
Escalation formula: "Escalating from [old SEV] to [new SEV] — [metric] went from [X] to [Y]. [Next action]."
Escalating is not a failure of the original triage — conditions change, and re-triaging quickly is exactly what a good incident commander is expected to do. Never silently downgrade urgency in your own head without communicating it.
4 / 14
A junior engineer pages the whole SRE team for a cosmetic CSS bug on a marketing page, calling it "urgent." What is the most constructive way to correct the severity assignment?
Correcting a mis-triage should (1) name the correct severity level with the reasoning, and (2) explain the consequence (paging thresholds) without being punitive — this is coaching, not blame.
Useful phrase: "Let's downgrade this to [SEV] because [criterion]; paging is reserved for [criteria]." Teaching new engineers the difference between "urgent to me" and "meets the paging threshold" is one of the most valuable things a senior engineer can model — it protects on-call sanity and keeps SEV1/SEV2 pages meaningful.
5 / 14
Sarah from Frontend noticed that the user login service is intermittently failing. The error rate has peaked at 8% over the last hour, and users are reporting being unable to access their accounts. She posts in #frontend-alerts: 'Login broken!' Which of the following responses best reflects an appropriate initial triage action?
The intermittent nature of the failure and the reported impact on users strongly suggest a severity issue. While an 8% error rate isn't a complete outage, it *is* significant enough to warrant SEV2 triage – a major functionality impairment. Assigning SEV1 would downplay the user-facing problem; sending it to DevOps is incorrect as this is a frontend service issue.
6 / 14
During a code review of a new payment processing API endpoint, David comments: 'This response time is atrocious! It's consistently over 5 seconds. Needs immediate attention.' Which phrasing best aligns with severity triage principles in this situation?
David's comment correctly identifies a performance issue that violates established service level agreements (SLAs). Exceeding SLA thresholds directly justifies SEV2 triage – a major functionality impairment. Simply 'monitoring' or 'optimizing' without an initial severity assessment is insufficient; the response needs to immediately acknowledge the impact and trigger escalation.
7 / 14
Maria in Incident Response receives a Slack message from Ben (a developer): 'URGENT! The API is returning 500 errors – looks like a database connection issue!' Which of the following responses would be most appropriate for Maria to send back, considering severity triage?
Ben's message is potentially alarming but lacks crucial context. Maria needs to gather more information before assigning a severity. Asking for impact details – users affected, services impacted - is essential for determining whether it warrants SEV1 or SEV2 triage. Dismissing the error or pushing for Jira updates without assessing the situation is irresponsible.
8 / 14
Alex writes a PR description for a fix to a reported bug in the user profile service: 'Fixed a typo in the JavaScript that was causing intermittent 503 errors. It's working now.' Which of the following phrases would be MOST appropriate to add to this description, from an incident response perspective?
Alex's description focuses solely on the immediate symptom (the typo) and doesn't acknowledge the underlying cause of the 503 errors. The potential for a configuration issue suggests a more serious problem that warrants further investigation – likely SEV2. Simply stating it's 'working now' is insufficient.
9 / 14
During the daily stand-up, Chloe reports: 'I spent the last hour debugging a performance issue with the recommendation engine. It's taking over 30 seconds to return results – much longer than usual.' Which action should Chloe take *immediately* after this report?
Chloe's report indicates a significant performance degradation impacting a core functionality (recommendations). A 30-second response time exceeds acceptable thresholds and demands immediate attention. Assigning SEV2 triggers escalation to ensure the issue is addressed with appropriate resources and priority – delaying action would exacerbate the problem.
10 / 14
Sarah from Frontend noticed that the user login service is intermittently failing. The error rate has peaked at 8% over the last hour, and users are reporting being unable to access their accounts. She posts in #frontend-alerts: 'Login broken!' Which of the following responses best reflects an appropriate initial triage action?
The intermittent nature of the failure and the reported impact on users strongly suggest a severity issue. While an 8% error rate isn't a complete outage, it *is* significant enough to warrant SEV2 triage – a major functionality impairment. Assigning SEV1 would downplay the user-facing problem; sending it to DevOps is incorrect as this is a frontend service issue.
11 / 14
During a code review of a new payment processing API endpoint, David comments: 'This response time is atrocious! It's consistently over 5 seconds. Needs immediate attention.' Which phrasing best aligns with severity triage principles in this situation?
David's comment correctly identifies a performance issue that violates established service level agreements (SLAs). Exceeding SLA thresholds directly justifies SEV2 triage – a major functionality impairment. Simply 'monitoring' or 'optimizing' without an initial severity assessment is insufficient; the response needs to immediately acknowledge the impact and trigger escalation.
12 / 14
Maria in Incident Response receives a Slack message from Ben (a developer): 'URGENT! The API is returning 500 errors – looks like a database connection issue!' Which of the following responses would be most appropriate for Maria to send back, considering severity triage?
Ben's message is potentially alarming but lacks crucial context. Maria needs to gather more information before assigning a severity. Asking for impact details – users affected, services impacted - is essential for determining whether it warrants SEV1 or SEV2 triage. Dismissing the error or pushing for Jira updates without assessing the situation is irresponsible.
13 / 14
Alex writes a PR description for a fix to a reported bug in the user profile service: 'Fixed a typo in the JavaScript that was causing intermittent 503 errors. It's working now.' Which of the following phrases would be MOST appropriate to add to this description, from an incident response perspective?
Alex's description focuses solely on the immediate symptom (the typo) and doesn't acknowledge the underlying cause of the 503 errors. The potential for a configuration issue suggests a more serious problem that warrants further investigation – likely SEV2. Simply stating it's 'working now' is insufficient.
14 / 14
During the daily stand-up, Chloe reports: 'I spent the last hour debugging a performance issue with the recommendation engine. It's taking over 30 seconds to return results – much longer than usual.' Which action should Chloe take *immediately* after this report?
Chloe's report indicates a significant performance degradation impacting a core functionality (recommendations). A 30-second response time exceeds acceptable thresholds and demands immediate attention. Assigning SEV2 triggers escalation to ensure the issue is addressed with appropriate resources and priority – delaying action would exacerbate the problem.
What will I practise in "Severity Triage Language — Incident Response English Exercise"?
Practise declaring, justifying, and escalating incident severity (SEV1–SEV4 / P0–P3) in clear, defensible English. 4 exercises for on-call engineers.
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.