3 exercises — master the essential metrics and terms every on-call engineer needs: SLI/SLO/SLA, MTTR/MTTD, and severity levels.
0 / 13 completed
1 / 13
A product manager asks: "What's the difference between an SLA, SLO, and SLI?" Which definition set is correct?
Option A is the correct industry-standard definition.
SLI (Service Level Indicator) — the raw metric you measure. Examples: request success rate, latency p99, error rate, availability %.
SLO (Service Level Objective) — your internal target for the SLI. Example: "99.9% of requests must succeed per rolling 30 days." SLOs are set by engineering teams and are aspirational. They are how you decide whether your service is "healthy".
SLA (Service Level Agreement) — a legal/contractual commitment to a customer. If you breach an SLA, there are consequences (refunds, escalation, etc.). SLAs are almost always set lower than your internal SLO to give you a buffer.
Relationship: SLI is measured → compared against SLO → if SLO is breached repeatedly → SLA may be breached → penalties apply.
2 / 13
In a post-mortem, a colleague writes: "MTTR was 52 minutes. MTTD was 28 minutes." What do these terms mean?
Option B is correct. These are the standard incident reliability metrics:
MTTD — Mean Time To Detect — the average time between when a problem first occurs and when your monitoring/alerting first detects it. In this example: 28 minutes passed before the alert fired. A high MTTD means your observability is poor.
MTTR — Mean Time To Recovery — the average time from when the incident started to when service was fully restored. In this example: 52 minutes total duration. (Some teams define MTTR as "Time To Repair", meaning the same thing.)
MTBF — Mean Time Between Failures (not shown here) — average time between incidents of the same type. A high MTBF means your system is stable.
These three metrics are core to SRE dashboards. Reducing MTTD (better alerting) and MTTR (better runbooks, automation) are common action items in post-mortems.
3 / 13
Your team classifies incidents by severity. Which definition of P1 and P0 is most accurate for most engineering teams?
Option B is the standard definition. Severity levels differ between organisations but the common pattern is:
P0 / SEV-0 — catastrophic. Complete platform down, critical data breach, payment processing failed entirely. All-hands war room. C-level may be notified. CEO/CTO is often pinged.
P1 / SEV-1 — critical. Major feature down for a significant percentage of users, SLA likely breached, on-call team mobilised immediately. Example: checkout broken for 30% of users.
P2 / SEV-2 — major. Significant but partial impairment. Response during business hours acceptable. Example: image uploads slow by 3×.
P3 / SEV-3 — minor. Small impact, workaround available. Schedule fix in next sprint.
Important: P0 is more severe than P1. Lower number = more critical. This is the opposite of what many non-technical people assume. Always clarify your organisation's severity matrix in the runbook.
4 / 13
Sarah (Lead DevOps) sends you a Slack message: 'We're seeing high CPU usage on the webserver-01. The logs show excessive calls to the /metrics endpoint. Can you investigate and determine if it's a spike or persistent issue?' What does 'persistent issue' typically imply in this context?
'Persistent issue' suggests more than just a momentary spike. It points to an ongoing problem that isn't just random noise. This demands further investigation beyond simply acknowledging the elevated CPU; it necessitates examining the root cause and potential long-term impacts on service performance.
5 / 13
You're reviewing a pull request for a new feature that adds logging around API calls. The PR description reads: 'Added logging to track requests to the /users endpoint. This will help with debugging and monitoring.' Which of the following best describes the *purpose* of this added logging, considering common incident response practices?
While audit trails and business insights are valuable, the phrase 'debugging and monitoring' strongly suggests a focus on immediate troubleshooting. Logging strategically placed around critical APIs allows developers to quickly trace requests, pinpoint bottlenecks, and diagnose issues during incidents – this is the core of incident response.
6 / 13
You receive the following API response from a monitoring service after an incident: `{"status":"error", "code":500,"message":"Internal Server Error - High database load.", "timestamp":1678886400}`. What is the most *immediate* action you should take based on this information?
The API response clearly points to 'High database load' as the underlying issue. Addressing this directly—by investigating the database – is the most immediate step towards resolving the error and preventing further incidents. While other actions are important, stabilizing the service takes precedence.
7 / 13
During a daily stand-up, your team lead asks: 'David (Backend Engineer) – what did you do yesterday?' David responds: 'I investigated the intermittent latency issues we were seeing in the payment processing service. I identified a race condition in the transaction logic and deployed a fix.' What is David primarily communicating about regarding this issue?
David highlights that he *resolved* an incident. This demonstrates not just identifying the problem (initial discovery) but successfully taking action to mitigate it – deploying a fix. The focus is on the outcome: restoring service and preventing further disruptions, which aligns with incident response principles.
8 / 13
You are writing a PR description for a change that improves error handling in a microservice. The description states: 'Implemented circuit breakers to prevent cascading failures and improve resilience.' What does the term 'circuit breaker' relate to within an incident response context?
Circuit breakers are specifically designed as a defensive strategy against cascading failures. When a service is failing repeatedly, the circuit breaker 'opens,' temporarily halting traffic to prevent overload and allow the underlying system to recover – this is a key element of resilience in incident response.
9 / 13
Sarah (Lead DevOps) sends you a Slack message: 'We're seeing high CPU usage on the webserver-01. The logs show excessive calls to the /metrics endpoint. Can you investigate and determine if it's a spike or persistent issue?' What does 'persistent issue' typically imply in this context?
'Persistent issue' suggests more than just a momentary spike. It points to an ongoing problem that isn't just random noise. This demands further investigation beyond simply acknowledging the elevated CPU; it necessitates examining the root cause and potential long-term impacts on service performance.
10 / 13
You're reviewing a pull request for a new feature that adds logging around API calls. The PR description reads: 'Added logging to track requests to the /users endpoint. This will help with debugging and monitoring.' Which of the following best describes the *purpose* of this added logging, considering common incident response practices?
While audit trails and business insights are valuable, the phrase 'debugging and monitoring' strongly suggests a focus on immediate troubleshooting. Logging strategically placed around critical APIs allows developers to quickly trace requests, pinpoint bottlenecks, and diagnose issues during incidents – this is the core of incident response.
11 / 13
You receive the following API response from a monitoring service after an incident: `{"status":"error", "code":500,"message":"Internal Server Error - High database load.", "timestamp":1678886400}`. What is the most *immediate* action you should take based on this information?
The API response clearly points to 'High database load' as the underlying issue. Addressing this directly—by investigating the database – is the most immediate step towards resolving the error and preventing further incidents. While other actions are important, stabilizing the service takes precedence.
12 / 13
During a daily stand-up, your team lead asks: 'David (Backend Engineer) – what did you do yesterday?' David responds: 'I investigated the intermittent latency issues we were seeing in the payment processing service. I identified a race condition in the transaction logic and deployed a fix.' What is David primarily communicating about regarding this issue?
David highlights that he *resolved* an incident. This demonstrates not just identifying the problem (initial discovery) but successfully taking action to mitigate it – deploying a fix. The focus is on the outcome: restoring service and preventing further disruptions, which aligns with incident response principles.
13 / 13
You are writing a PR description for a change that improves error handling in a microservice. The description states: 'Implemented circuit breakers to prevent cascading failures and improve resilience.' What does the term 'circuit breaker' relate to within an incident response context?
Circuit breakers are specifically designed as a defensive strategy against cascading failures. When a service is failing repeatedly, the circuit breaker 'opens,' temporarily halting traffic to prevent overload and allow the underlying system to recover – this is a key element of resilience in incident response.
What will I practise in "On-Call Vocabulary — Incident Response English Exercise"?
Learn and practise on-call and SRE vocabulary: SLA vs SLO vs SLI, MTTR, MTTD, MTBF, and P0–P4 severity levels. 3 beginner-friendly exercises.
How many exercises are in this module?
This module has 13 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.