5 exercises — Practice the English for error budget policy enforcement, burn rate interpretation, and linking reliability to deployment velocity.
0 / 10 completed
1 / 10
An SRE team has an SLO of 99.9% availability. After a P1 incident, the team reviews their status page: "We've burned 68% of our monthly error budget in the first two weeks." What would be the most appropriate response language in the next engineering review?
Burning >50% of the budget mid-month is the trigger for error budget policy enforcement.
An error budget policy defines what happens when the budget is consumed beyond a threshold. Common policy tiers:
• Yellow (50% burned): Increase monitoring, slow release cadence
• Orange (80% burned): Freeze non-critical deployments
• Red (100% burned/SLO breached): Full deployment freeze, all hands on reliability
Lowering the SLO to create more room is considered a last resort and requires stakeholder agreement — it's not a fix, it's an acceptance of lower reliability.
Key vocabulary:
• Error budget policy — agreed rules for what changes when budget is depleted
• Budget burn — the rate at which error budget is being consumed
• Deployment freeze — halting all releases to protect remaining budget
• Reliability work — engineering effort directed toward fixing the root causes of budget burn
2 / 10
A monitoring alert fires at 3 AM with the message: "SLO burn rate alert — 14.4× fast burn detected on checkout-api over the last 1 hour." Which statement best describes what "14.4× fast burn" means?
Burn rate is a multiplier — 1× is the "sustainable" pace, anything above 1× means accelerated consumption.
If the monthly error budget at 99.9% SLO is 43.2 minutes (720 hours × 0.1% = 43.2 min), then:
• 1× burn rate = budget exhausted in exactly 30 days
• 14.4× burn rate = budget exhausted in 30 ÷ 14.4 ≈ 2.08 days
The Google SRE recommendation uses a multi-window burn rate alert: a fast (1h/5min) window catches sharp spikes, a slow (6h/30min) window catches sustained degradation.
Key vocabulary:
• Burn rate — how fast the error budget is being consumed relative to the SLO window
• 14.4× burn rate — Google's recommended threshold for a "page immediately" alert at 99.9% SLO
• Fast burn window — short lookback period (1h) catches sudden spikes
• Slow burn window — longer lookback period (6h) catches sustained degradation below the page threshold
3 / 10
After a successful month with zero incidents, the SRE lead says in the retrospective: "Our error budget is 100% remaining. Per our policy, the product team has full deployment freedom this month." What concept does "full deployment freedom" represent here?
The error budget model intentionally links reliability to feature velocity.
This is the core insight of the SRE error budget concept: instead of reliability and feature development being adversarial, the error budget creates a shared incentive.
• When the budget is healthy → product teams have freedom to take risks (deploy frequently, try bold features)
• When the budget is depleted → both product and SRE pause and invest in reliability
The phrase "deployment freedom" is common in SRE conversations. It's the positive framing of the budget: it's not just a limit on downtime, it's credit you earn for being reliable.
Key vocabulary:
• Deployment freedom — earned right to move fast when reliability is strong
• Feature velocity — rate at which new features are shipped
• Error budget as currency — the metaphor that reliability earns the right to take deployment risk
• Shared incentive — product and SRE both benefit from maintaining the error budget
4 / 10
An SRE writes a post-incident report. In the error budget section, they write: "The incident consumed 4.7 minutes of our 21.6-minute monthly budget — 21.76% of the budget." The report then describes this as "significant budget consumption." Why is this framing useful?
Budget percentage normalizes incidents across services with different SLOs.
"4.7 minutes of downtime" sounds minor in isolation. But expressed as "21.76% of the monthly budget" you know this was a significant event for a service with a 99.95% SLO.
For a service with a 99% SLO, 4.7 minutes would be only 1% of budget — much less significant.
This normalization allows:
• Comparing incident severity across services
• Communicating risk to product and leadership consistently
• Tracking trend: "Are our incidents getting larger or smaller relative to budget?"
Key vocabulary:
• Budget consumption — how much of the error budget a specific incident used
• Significant budget event — incident that consumed more than ~10% of the budget
• Incident severity classification by budget impact — using budget % to grade incidents
• Normalized incident cost — incident impact expressed relative to the error budget
5 / 10
A product manager emails the SRE team: "Can we ship the database migration on Friday? We know it carries risk." The SRE lead responds: "We currently have 8% of our monthly error budget remaining with 12 days left in the window. Based on our error budget policy, I'd recommend holding the migration until next month." What is the SRE using as the decision framework?
The error budget policy provides an objective, pre-agreed framework for deployment decisions.
With 8% remaining and 12 days left, the team needs that budget to cover normal variability. A risky deployment could easily exhaust it, causing an SLO breach.
Key math: 8% of the budget to cover 40% of the remaining window = the team is running hot. Any additional incident risk is not justified.
The error budget policy transforms a subjective conversation ("I think it's risky") into an objective one ("per our policy, we're in the yellow/orange zone — here's what we agreed to do").
Key vocabulary:
• Holding until next window — deferring a risky change until the error budget resets
• Risk-adjusted deployment decision — using remaining budget to decide whether to absorb deployment risk
• Policy-driven decision — the SRE cites policy, not personal judgment
• Budget reset — the start of a new measurement window (typically monthly)
6 / 10
During a code review of a new feature for user authentication, Alice comments: 'This change seems to be eating up a significant portion of our error budget. I'm seeing a spike in failed login attempts – roughly 12x the baseline.' Bob, a more junior developer, asks, 'What exactly does '12x the baseline' mean in this context?' Which response best explains Bob's question?
The phrase '12x the baseline' refers to a rate comparison. It signifies that the observed number of failed login attempts (the numerator) is twelve times higher than the typical or expected error rate for that particular service (the denominator). Misunderstanding this implies simply a large number of errors, ignoring the comparative context crucial for understanding budget consumption.
7 / 10
Sarah, an SRE, is drafting a Slack message to inform the team about a potential problem. She writes: 'Our SLO for API response times is 99.5%, and we're currently burning through 75% of our error budget in the last week. This suggests we need to investigate further.' What does Sarah primarily use as the basis for this assessment?
Sarah's message highlights the relationship between error budget consumption and SLO adherence. The 'burn rate' (75%) is being compared against the overall error budget; this represents a deviation from the desired SLO target (99.5%). The team needs to investigate *why* they are exceeding the budget, which directly impacts their ability to meet the defined service level.
8 / 10
David, a DevOps engineer, is reviewing a pull request for a new deployment pipeline. The PR description includes this section: 'This deployment consumes approximately 3 minutes of our 15-minute monthly error budget.' What does this statement most accurately describe?
The statement frames '3 minutes' within the context of the monthly error budget. The error budget represents a *time* allocation – it's the maximum allowable duration for an incident or failed operation before impacting the SLO. Therefore, this describes the *limit* on acceptable downtime defined by that specific deployment.
9 / 10
During a standup meeting, Mark (SRE) says: 'We've used up 20% of our error budget on this new feature release.' Lisa (Product Manager) asks, 'What does that mean in practical terms?' Which response from Mark best clarifies Lisa's question?
The error budget isn't an absolute constraint on *value* – rather, it defines the allowable period for incident response and recovery. Mark is explaining that with 80% remaining, there's a defined window to address any problems related to the release without triggering further SLA breaches or impacting the overall SLO.
10 / 10
Emily (SRE) is explaining the error budget policy to a new team member. She says: 'We have a monthly error budget of 60 minutes. If we exceed that, we need to justify the extra cost and potentially reduce our deployment frequency.' What primary goal does this statement reflect?
The statement highlights the trade-off between rapid incident response and maintaining an acceptable level of risk. The 'error budget' acts as a constraint on the team's ability to immediately fix every issue – forcing them to consider the broader impact and potentially reduce deployment frequency if exceeding the limit consistently.
What will I learn from the "Error Budget Language — SLO & Error Budget Engineering English" exercise?
Practice the English vocabulary for error budgets: burn rate language, budget policy discussions, deployment freedom, and communicating budget consumption in incident reviews.
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.