5 exercises — Practice the English for burn rate alert configuration, multi-window alerting, distinguishing fast vs. slow burn, and eliminating alert noise.
0 / 10 completed
1 / 10
A monitoring engineer configures an SLO alert and writes in the runbook: "This alert fires when the 1-hour burn rate exceeds 14.4×. Page the on-call immediately." What does this alert configuration detect?
14.4× is a significant threshold: the budget would be exhausted in ~2 days at this burn rate.
The math: monthly error budget ÷ 14.4 = 30 days ÷ 14.4 ≈ 2.08 days until total exhaustion.
Google SRE recommends this as a page-immediately threshold for services with a 99.9% SLO on a 30-day window.
Why 14.4×? It detects incidents significant enough to exhaust the budget within 2 days while still being specific enough to avoid false alarms for minor degradation.
Key vocabulary:
• Burn rate multiplier — 1× means the budget will last exactly the window; > 1× means faster consumption
• Page threshold — burn rate high enough to warrant waking up the on-call engineer
• Budget exhaustion time — window ÷ burn rate = days until the budget runs out
• Ticket threshold — lower burn rate that creates a ticket but doesn't page
2 / 10
An SRE team implements a multi-window, multi-burn-rate alerting strategy. The alert spec reads: "Fire if the 1-hour window shows > 14.4× burn rate AND the 5-minute window also shows > 14.4× burn rate." Why require BOTH windows to fire simultaneously?
Multi-window alerting combines a short lookback (spike detection) with confirmation from a longer lookback (sustained problem).
Single-window alerting problems:
• 5-minute only → too noisy; momentary spikes trigger false alarms
• 1-hour only → slow to detect sudden complete failures
Multi-window solution: require BOTH to fire simultaneously.
• 1-hour + 5-min both hot → the incident has been ongoing AND is currently severe
• Only 1-hour hot → ongoing slow degradation (lower-severity ticket)
• Only 5-min hot → spike started recently; wait for 1-hour confirmation
Key vocabulary:
• Multi-window burn rate alert — alert requiring multiple time windows to confirm severity
• False positive — alert that fires for a transient blip that self-recovers
• Short lookback window — recent window (1h, 5min) catches current state
• Long lookback window — longer window (6h, 1h) confirms sustained degradation
3 / 10
An alert fires at 2 AM saying: "Slow burn detected: 6-hour burn rate = 3× on checkout-api." The engineer on call decides to create a ticket but not page anyone else. Is this the correct response?
The correct response depends on the burn rate and time available before budget exhaustion.
Decision framework:
• 3× burn rate → budget exhausts in 30 ÷ 3 = 10 days → investigate during business hours (ticket)
• 6× burn rate → budget exhausts in 5 days → escalate to next-business-day review (ticket + notification)
• 14.4× burn rate → budget exhausts in 2 days → page on-call immediately
• 36× burn rate → budget exhausts in ~20 hours → SEV-1 incident
Not every alert should wake someone up — calibrating alert thresholds to required response urgency is a key SRE practice.
Key vocabulary:
• Slow burn alert — sustained degradation at a low-to-medium rate; creates ticket, no immediate page
• Fast burn alert — rapid degradation requiring immediate human response
• Response urgency — how quickly action is required based on budget exhaustion time
• Alert severity tiering — categorizing alerts by urgency and required response type
4 / 10
An SRE team reviews their alerts and notices that 70% of their SLO alerts are resolved before the on-call engineer even investigates. What is this pattern called and what does it indicate?
If most alerts self-resolve, the alert thresholds are wrong — they're catching noise, not signal.
The principle: Every alert should require a specific human action. An alert that resolves itself before the engineer can act is by definition not actionable.
Fixes for noisy SLO alerts:
• Increase the burn rate threshold (e.g., from 2× to 5×)
• Add a minimum duration requirement (e.g., must sustain for 10+ minutes)
• Switch to multi-window alerting to require sustained degradation
• Remove alerts for SLO components with inherently high variance
Key vocabulary:
• Alert flapping — alert that fires and clears repeatedly without human action
• Non-actionable alert — alert that doesn't require (or enable) a specific human response
• Alert fatigue — engineers habituate to alerts and stop responding carefully
• Alert signal-to-noise ratio — proportion of meaningful alerts vs. false alarms
5 / 10
An engineer proposes: "Instead of alerting on burn rate, let's just alert when the SLO compliance drops below 99.9% for the month." An SRE lead objects. What is the main problem with this approach?
Burn rate alerting provides early warning before the SLO is breached; compliance alerting only fires after the breach.
Analogy: Burn rate alerting is like a fuel gauge warning at 25% — it gives you time to act. Compliance alerting is like a warning that fires when the tank is empty and you've already stopped.
The goal of SLO alerting is to give the team time to:
1. Detect the problem
2. Diagnose root cause
3. Implement a fix
4. Recover reliability
5. Have budget remaining to absorb future incidents
Burn rate alerting with multi-window tiers gives warning when there's still ~10+ days of budget left.
Key vocabulary:
• Proactive alerting — detecting problems before the SLO is breached
• Reactive alerting — detecting that the SLO has already been breached (too late)
• Breach detection vs. breach prevention — the key distinction in alerting strategy
• Budget-based alerting — alerting based on consumption rate, not absolute compliance level
6 / 10
Code Review Comment: 'This metric feels overly sensitive. We're seeing spikes due to nightly batch jobs, and this alert is triggering every time. Shouldn't we consider a more nuanced approach?' What does the reviewer *likely* mean when discussing an 'SLO-based alert' in this context?
The reviewer is questioning the direct application of an SLO target without considering contributing factors. A truly SLO-based alert focuses on *why* a metric deviates from the target, not just that it does. The comment highlights a critical step in error budget engineering: understanding the root cause before reacting with an alert.
7 / 10
Slack Message from a Developer: 'Just ran some diagnostics on the payment service. The error budget is depleted, and the SLO for successful transactions is down to 95%. I've flagged it for the team.' What does the developer *primarily* convey with this message?
While the message *hints* at a problem, it's focused on the relationship between the error budget and SLO compliance. The developer isn't stating an outage; they are reporting that the service is violating its defined boundaries, indicating a potential issue requiring investigation within the context of the overall operational goals.
8 / 10
PR Description: 'Adding monitoring for API latency. Alerting will be configured based on a 5-minute moving average exceeding 200ms. This helps us proactively identify potential performance degradation and maintain our SLO of 99.9% availability.' What is the *primary* benefit of using a 5-minute moving average in this alert configuration?
A moving average smooths out transient fluctuations in latency, making it easier to identify sustained deviations from the target. This is crucial for SLO-based alerting because short spikes may not be indicative of a serious problem but could still impact user experience and trigger unnecessary alerts if only based on instantaneous measurements.
9 / 10
Standup Update from an SRE: 'We've been monitoring the database query latency. We're seeing a trend towards higher average query times, which is impacting our SLO for application response time. We're investigating potential schema changes.' What key aspect of SLO management is highlighted in this update?
This update emphasizes that simply having an alert isn't enough; it needs to be tied to a strategy for adapting thresholds. The SRE is acknowledging they are seeing a trend and immediately thinking about how this will impact their alerting configuration – a core part of error budget management.
10 / 10
Code Review Comment: 'Let's just alert when the number of failed requests exceeds 500 per minute. That'll catch anything serious.' What is the *most significant* potential problem with this proposed alerting strategy, considering SLO engineering?
Alerting solely on request volume without considering SLO targets or underlying metrics is highly susceptible to generating false positives. A high number of failed requests could be due to legitimate traffic spikes, a temporary service issue, or something entirely unrelated – without context, the alert doesn't provide actionable insights and risks exhausting the error budget.
What will I learn from the "SLO-Based Alerting Vocabulary — SLO & Error Budget Engineering English" exercise?
Practice the English vocabulary for SLO-based alerting: multi-window burn rate alerts, fast vs. slow burn thresholds, alert noise reduction, and proactive vs. reactive alerting.
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 required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this SLO Engineering exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss slo engineering topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more SLO Engineering exercises?
See the full SLO Engineering exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.