5 exercises — the vocabulary every SRE, DevOps, and backend engineer needs to respond to and communicate about production incidents: blast radius, postmortems, escalation, war rooms, and runbooks.
Core incident response vocabulary clusters
Impact terms: blast radius, scope of impact, SEV-1/2/3, affected users, degraded service
Process terms: triage, contain, investigate, mitigate, resolve, post-incident review
Roles: incident commander (IC), on-call engineer, communication lead, scribe
Metrics: MTTA (mean time to acknowledge), MTTR (mean time to resolve), error rate, SLA breach
The incident commander says on a call: "We've identified the blast radius — it's only the payments service, the rest of the platform is operating normally. Let's contain it before we investigate root cause." What does blast radius mean in incident response?
Blast radius is borrowed from military/explosive terminology and means the scope of impact of a failure — which systems, services, or users are affected. Minimising blast radius is a core reliability engineering principle: design systems so a single failure can't cascade across your entire platform. Common blast radius limitation techniques: Bulkheads — isolate services so one failure doesn't exhaust shared resources. Circuit breakers — stop calls to a failing service so failures don't propagate. Cell-based architecture — route users to independent cells so an issue in Cell A doesn't affect Cell B. Feature flags — toggle features off for subsets of users without a full deployment rollback. In incident response: before fixing, you first contain (limit blast radius), then investigate (root cause), then fix, then learn (postmortem). In conversation: "The canary deployment caught the bug early — blast radius was under 1% of traffic before we rolled back."
2 / 10
A postmortem document states: "After the incident was resolved, the team conducted a blameless postmortem, identifying four contributing factors and six action items to prevent recurrence." What does blameless postmortem mean?
A blameless postmortem (also called a learning review or post-incident review) is a structured analysis of what went wrong, designed to improve systems and processes rather than punish individuals. The philosophy: engineers operating in complex systems make rational decisions based on the information they had at the time. When things go wrong, the system — not the individual — usually created the conditions for failure. Pioneered by Google SRE and the DevOps movement. Blameless postmortem structure: Timeline — what happened and when (constructed from logs, alerts, chat history). Impact — user/revenue/SLA impact. Contributing factors — usually 3–5 systemic causes (not a single person's mistake). What went well — detection speed, communication, mitigation effectiveness. Action items — specific, assigned, time-bound improvements. A blame culture leads to hiding mistakes and under-reporting incidents; a blameless culture promotes transparency and organisational learning. In conversation: "The postmortem was blameless — we focused on why the monitoring didn't alert us earlier, not on who deployed the change."
3 / 10
An SRE explains their on-call setup: "We use an escalation policy — if the primary on-call doesn't acknowledge the alert within five minutes, it automatically pages the secondary, and then the engineering manager." What is an escalation policy?
An escalation policy defines who gets paged, in what order, and after how long if an earlier responder doesn't acknowledge an alert. It ensures every alert gets a human response even if the primary on-call is asleep, unavailable, or overwhelmed. Escalation policy components: Acknowledgement timeout — how long before escalating (typically 5–15 min). Escalation chain — primary → secondary → team lead → engineering manager. Repeat interval — how often to re-page if unacknowledged. Override schedule — holiday and weekend coverage rules. Common tools: PagerDuty, Opsgenie, VictorOps (now Splunk On-Call). Related vocabulary: On-call rotation — the schedule defining who is primary on-call and when. Acknowledgement (ACK) — the responder confirms they've seen and are handling the alert. MTTA — Mean Time To Acknowledge. MTTR — Mean Time To Resolve. Runbook — step-by-step instructions for responding to a specific alert type. In conversation: "We reduced MTTA from 12 minutes to 3 minutes after rewriting our escalation policy to reduce the acknowledgement window."
4 / 10
During a live incident, the incident commander says: "Let's declare this a SEV-1. I'm setting up a war room — all non-essential responders please leave the channel. We need clean communication." What is a war room in incident response?
A war room is a dedicated, time-boxed communication space — a Slack channel, Zoom call, or physical room — where incident responders focus exclusively on resolving a major outage. Non-essential people are excluded to reduce noise and keep communication clear. Incident communication best practices: Dedicated channel — create a new incident channel (e.g., #inc-20240315-payments) to separate incident comms from general chat. Incident commander (IC) — one person owns the incident, delegates tasks, and decides the resolution strategy. Communication lead — a separate person drafts status page updates and internal stakeholder comms so the IC can focus on resolution. Scribe — records timeline, decisions, and action items for the postmortem. Status page — external-facing updates for affected customers (e.g., via Statuspage.io, Atlassian Status). SEV levels: SEV-1 — critical, major user impact, all hands. SEV-2 — significant impact. SEV-3 — degraded performance, non-critical. SEV-4 — minor issue, no user impact. In conversation: "The war room stayed open for 4 hours until we confirmed all affected transactions had recovered."
5 / 10
An SRE writes in a runbook: "If the database CPU exceeds 90% for more than 5 minutes, execute a manual failover to the read replica. Document the exact time and promote this replica to primary." What is a runbook?
A runbook (also called an operations playbook or standard operating procedure / SOP) is a documented set of procedures for handling a specific operational scenario — typically a recurring incident type or scheduled operational task. Runbook contents: Alert trigger — what alert fires and what conditions caused it. Diagnosis steps — how to confirm the issue and assess impact. Resolution steps — numbered, specific actions to take. Verification — how to confirm the issue is resolved. Escalation — when and who to escalate to if the runbook doesn't resolve the issue. Runbook types: Break-fix runbooks — reactive, for handling specific alert types. Operational runbooks — for scheduled tasks (deployments, database maintenance, key rotation). Disaster recovery runbooks — for major failure scenarios. Runbooks are key to reducing MTTR and enabling on-call engineers to handle incidents they didn't originally build. In conversation: "The on-call engineer followed the database failover runbook and had us back in 8 minutes, even though they'd never handled this incident type before."
6 / 10
Sarah, a junior developer, sends this message to the #devs Slack channel: 'The API is returning 503 errors intermittently. It's affecting user authentication. Looks like a transient issue – we should just monitor it.' What does 'transient issue' mean in the context of an incident?
'Transient issue' refers to an event that appears serious but quickly disappears. It's often used when describing short-lived problems like network glitches or temporary server overload, where the root cause isn't immediately apparent and doesn't represent a fundamental system failure. The key is its temporary nature – it resolves itself without requiring immediate intervention; Sarah was underestimating the potential impact of intermittent authentication failures.
7 / 10
During a standup meeting, David says: 'Yesterday, we identified a high latency spike in our image processing service. We rolled out a temporary fix – reducing the batch size – and it's stabilized for now. We're investigating further to understand the root cause.' What is David referring to when he mentions 'rolling out a temporary fix'?
'Rolling out a temporary fix' describes a rapid deployment of a solution designed solely to alleviate immediate symptoms without addressing the underlying problem. It's a common practice in incident response when time is critical and a fully tested permanent solution isn't yet available – David was prioritizing stability over a deep dive at that moment.
8 / 10
You're reviewing a pull request for a new feature. The PR description reads: 'Implemented the user profile update functionality. Added validation to ensure data integrity. This change should be thoroughly tested before merging.' What does 'data integrity' refer to in this context?
'Data integrity' in software development refers to the assurance that data remains accurate and consistent throughout its lifecycle. It encompasses ensuring that data isn't corrupted during storage or retrieval, a crucial aspect of reliable application functionality – this is about preventing incorrect user profile information from being stored.
9 / 10
As the lead on an incident involving a failing microservice, you instruct the team to 'throttle requests' to prevent further degradation. What does 'throttle requests' mean in this scenario?
'Throttle requests' means to restrict the number of incoming requests that a system can handle within a given timeframe. This is a common technique used during incidents to alleviate load on a stressed service and prevent further issues – it's a form of rate limiting designed to stabilize the system.
10 / 10
During an incident involving a database outage, the SRE team utilizes a 'cold standby' configuration. What does 'cold standby' mean in this context?
'Cold standby' refers to a backup system that is powered on and ready for immediate activation in case of a failure. However, it's not actively serving requests; it remains idle until triggered – this contrasts with 'warm standby,' which is actively synchronized.
These modules build the same on-the-job skills as Incident Response Vocabulary
— work through them together for a fuller vocabulary set.
Incident Command System— useful for Incident command & communication (SRE / Platform Engineer)
Frequently Asked Questions
What does the "Incident Response Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to incident response vocabulary through 10 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 1 other vocabulary module. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.