Practice incident severity level language: SEV-1 through SEV-4 definitions, declaring and downgrading severity, impact assessment, customer-impacting vs internal-only classification.
0 / 15 completed
1 / 15
An on-call engineer pages the incident commander with the message: "Declaring SEV-1 — checkout is down for all customers." What does declaring SEV-1 typically mean?
Declaring SEV-1 triggers a specific protocol: IC assumes command, war room opens, comms lead drafts status page update, executive sponsor is notified, engineering is mobilised. The word 'declaring' is deliberate — it is an active, formal act, not a passive observation. Different companies define SEV-1 differently, but common criteria: 100% of customers impacted, core revenue-generating functionality unavailable, or potential for significant data loss.
2 / 15
What is the typical distinction between a SEV-2 and SEV-3 incident?
SEV definitions vary by company but the general pattern: SEV-1 (critical, total outage), SEV-2 (major impact, significant degradation), SEV-3 (partial impact, workarounds available), SEV-4 (minor issue, cosmetic or low-usage). The distinction drives response: SEV-2 gets a dedicated IC and war room; SEV-3 might be handled by the on-call engineer with regular status updates. Mis-classifying severity (calling a SEV-1 a SEV-3) is a common failure mode that delays appropriate response.
3 / 15
An incident commander says on the bridge: "Based on the new information, I'm downgrading this to SEV-2." When is downgrading severity appropriate?
Downgrading severity should be based on facts, not wishful thinking or social pressure. Valid reasons to downgrade: customer impact is less than initially thought, a mitigation is in place that restores most functionality, or the affected component is non-critical. Downgrading changes the response protocol — fewer people on the bridge, longer update cadence, different executive involvement. It should be communicated clearly: 'Downgrading to SEV-2 because [specific reason]. IC remains active, next update in 30 minutes.'
4 / 15
An incident is classified as 'customer-impacting.' What does this classification trigger compared to an 'internal-only' incident?
The customer-impacting vs internal-only classification drives the communications protocol. Customer-impacting: status page must be updated within a defined SLA (often 15-30 minutes), customer-facing support must be briefed, account managers may need to notify enterprise customers proactively, and the incident post-mortem must include customer communication review. Internal-only: no external communication required, but internal SLAs still apply and a post-mortem is still conducted.
5 / 15
A post-incident review notes: "Impact assessment was delayed by 20 minutes because the team lacked tooling to identify affected customer percentage." Why is rapid impact assessment critical in incident response?
Impact assessment — 'how many customers are affected, and how?' — is the first priority after detecting an incident. It feeds severity classification, which feeds everything else. Teams invest in impact assessment tooling: dashboards showing affected users in real time, automated alerting with customer impact context, and runbooks with impact query templates. Common impact metrics: % of requests erroring, number of affected accounts, revenue impact per minute of downtime, geographic scope.
6 / 15
Sarah (Senior Developer) posts on Slack: 'Looks like we're seeing high latency on the payment API. Users are reporting slow checkout times.' As an incident responder, what is the most appropriate initial severity classification for this situation?
Declaring SEV-1 indicates a critical incident – specifically, 'customer impact.' Slow checkout times directly translate to lost sales and dissatisfied users. While latency itself can be a symptom of other issues, the explicit mention of 'slow checkout' strongly suggests SEV-1 due to the immediate potential for financial harm. Options B, C, and D are too low severity classifications for this scenario.
7 / 15
You're reviewing a pull request describing an incident: 'The service experienced intermittent outages during peak hours. Error rates spiked to 5% but quickly returned to normal.' Which of the following best describes the difference in severity between this situation and one classified as SEV-2?
SEV-2 generally signifies a more substantial impact than SEV-1. It's not *just* about high error rates; it requires that those errors are causing demonstrable harm – in this case, intermittent outages during peak hours affecting user experience. Options B and D misunderstand the core principle of severity classification which is tied to business impact.
8 / 15
During a post-incident meeting, the Incident Commander states: 'We're increasing the severity from SEV-3 to SEV-2 based on new telemetry data showing that 30% of users were experiencing errors.' What is the primary justification for this change?
The core reason for changing severity is a revised impact assessment. The original SEV-3 classification was based on incomplete information. New telemetry data (30% error rate) provided sufficient evidence to demonstrate a greater level of customer or business disruption – justifying the move to SEV-2, which demands a higher degree of impact.
9 / 15
A PR description for a fix states: 'This resolves an issue where users were intermittently unable to access their accounts after the recent database migration.' Considering this situation, what is the most accurate classification of its impact?
The description clearly indicates 'intermittently unable to access their accounts,' meaning a subset of users are affected. While it doesn't specify *how many*, the core issue – inability to access a service – represents a significant impact on user experience and functionality, justifying SEV-2. Options A and D misinterpret the severity based on completeness or lack thereof.
10 / 15
During a standup update, a developer says: 'We're seeing increased CPU utilization on our message queue. We haven't been able to determine the exact number of affected users yet.' What is the immediate consequence of this classification?
When the exact number of affected users isn't known, it's crucial to adopt a cautious approach. Classifying this as SEV-3 (or even monitoring only) would be premature – without understanding *who* is impacted and the degree of impact, escalating to SEV-1 would be inappropriate. The priority is investigation and continuous monitoring until the impact can be quantified.
11 / 15
Sarah (Senior Developer) posts on Slack: 'Looks like we're seeing high latency on the payment API. Users are reporting slow checkout times.' As an incident responder, what is the most appropriate initial severity classification for this situation?
Declaring SEV-1 indicates a critical incident – specifically, 'customer impact.' Slow checkout times directly translate to lost sales and dissatisfied users. While latency itself can be a symptom of other issues, the explicit mention of 'slow checkout' strongly suggests SEV-1 due to the immediate potential for financial harm. Options B, C, and D are too low severity classifications for this scenario.
12 / 15
You're reviewing a pull request describing an incident: 'The service experienced intermittent outages during peak hours. Error rates spiked to 5% but quickly returned to normal.' Which of the following best describes the difference in severity between this situation and one classified as SEV-2?
SEV-2 generally signifies a more substantial impact than SEV-1. It's not *just* about high error rates; it requires that those errors are causing demonstrable harm – in this case, intermittent outages during peak hours affecting user experience. Options B and D misunderstand the core principle of severity classification which is tied to business impact.
13 / 15
During a post-incident meeting, the Incident Commander states: 'We're increasing the severity from SEV-3 to SEV-2 based on new telemetry data showing that 30% of users were experiencing errors.' What is the primary justification for this change?
The core reason for changing severity is a revised impact assessment. The original SEV-3 classification was based on incomplete information. New telemetry data (30% error rate) provided sufficient evidence to demonstrate a greater level of customer or business disruption – justifying the move to SEV-2, which demands a higher degree of impact.
14 / 15
A PR description for a fix states: 'This resolves an issue where users were intermittently unable to access their accounts after the recent database migration.' Considering this situation, what is the most accurate classification of its impact?
The description clearly indicates 'intermittently unable to access their accounts,' meaning a subset of users are affected. While it doesn't specify *how many*, the core issue – inability to access a service – represents a significant impact on user experience and functionality, justifying SEV-2. Options A and D misinterpret the severity based on completeness or lack thereof.
15 / 15
During a standup update, a developer says: 'We're seeing increased CPU utilization on our message queue. We haven't been able to determine the exact number of affected users yet.' What is the immediate consequence of this classification?
When the exact number of affected users isn't known, it's crucial to adopt a cautious approach. Classifying this as SEV-3 (or even monitoring only) would be premature – without understanding *who* is impacted and the degree of impact, escalating to SEV-1 would be inappropriate. The priority is investigation and continuous monitoring until the impact can be quantified.
What will I practise in "Incident Severity Vocabulary"?
Practice incident severity level language: SEV-1 through SEV-4 definitions, declaring and downgrading severity, impact assessment, customer-impacting vs internal-only classification.
How many exercises are in this module?
This module has 15 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 Command Language exercises?
Browse the full Incident Command Language 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.