SRE Error Budgets & SLI/SLO Management 2 — Questions and Answers
Question 1: An error budget has been fully consumed three weeks before the end of the quarter. What is the MOST appropriate response?
- Freeze all non-critical feature releases and focus on reliability work (Correct answer)
- Increase the SLO target to automatically replenish the error budget
- Ignore the depletion since SLOs reset at the start of the next quarter
- Reduce monitoring frequency to lower the number of detected incidents
Correct answer: Freeze all non-critical feature releases and focus on reliability work
When the error budget is exhausted, the standard SRE practice is to halt feature work and redirect engineering effort toward reliability improvements until the budget recovers.
An error budget represents the acceptable amount of unreliability for a service within a given window. When that budget is fully consumed, the implicit contract between SRE and product teams is broken — no further risk can be introduced. Freezing non-critical releases and focusing on reliability work (reducing toil, fixing root causes, improving monitoring) is the canonical SRE response. Increasing the SLO target would make the SLO weaker, not fix the reliability issue. Ignoring depletion defeats the purpose of the error budget framework. Reducing monitoring hides problems rather than solving them.
Question 2: Which formula correctly expresses the error budget for a 99.9% monthly SLO?
- 0.1% of total minutes in the month ≈ 43.8 minutes of allowed downtime (Correct answer)
- 1.0% of total minutes in the month ≈ 438 minutes of allowed downtime
- 0.01% of total minutes in the month ≈ 4.38 minutes of allowed downtime
- 99.9% of total minutes in the month ≈ 43,756 minutes of allowed downtime
Correct answer: 0.1% of total minutes in the month ≈ 43.8 minutes of allowed downtime
Error budget = (1 − SLO) × measurement window. For 99.9% over ~43,800 minutes/month: 0.001 × 43,800 ≈ 43.8 minutes.
The error budget is the complement of the SLO: (1 − 0.999) = 0.001, or 0.1%. A standard month contains approximately 43,800 minutes (30.4 days × 24 hours × 60 minutes). Multiplying 43,800 × 0.001 gives approximately 43.8 minutes of allowed downtime or degraded service. This figure is the 'budget' engineering teams can spend on risky deployments, experiments, and unavoidable outages. Understanding the arithmetic is essential for setting meaningful SLOs and communicating risk to stakeholders.
Question 3: A team defines a latency SLI as 'the proportion of homepage requests served in under 200 ms.' Which SLO statement is BEST aligned with this SLI?
- 99% of homepage requests will be served in under 200 ms over a rolling 28-day window (Correct answer)
- Homepage average latency will not exceed 200 ms per calendar month
- Homepage p99 latency will not exceed 200 ms as measured at the load balancer
- Homepage requests will succeed 99.9% of the time within a 30-day window
Correct answer: 99% of homepage requests will be served in under 200 ms over a rolling 28-day window
An SLO must reference the same SLI metric and unit. The SLI is the proportion of requests under 200 ms, so the SLO should set a target percentage for that same proportion over a defined time window.
SLIs measure a specific aspect of service quality (e.g., fraction of fast requests), and SLOs set a numerical target for that SLI over a time window. Option A directly maps to the defined SLI: it specifies the same proportion metric (requests under 200 ms), sets a target (99%), and defines the measurement window (rolling 28 days). Option B uses average latency, which is a different and weaker metric than a proportional SLI. Option C describes a percentile measurement, not the proportional SLI defined. Option D measures availability (success rate), not latency.
Question 4: What is the PRIMARY risk of setting SLO targets that are too high (e.g., 99.999%)?
- The error budget becomes so small that even minor incidents exhaust it, blocking all feature development (Correct answer)
- Customers will always expect more than 99.999% reliability in future contracts
- Monitoring systems cannot accurately measure reliability at that level
- Engineering teams will have too much free time since incidents are rare
Correct answer: The error budget becomes so small that even minor incidents exhaust it, blocking all feature development
An extremely tight SLO leaves almost no error budget, meaning even routine deployments or brief incidents will exhaust the budget and force a reliability freeze on feature work.
99.999% availability over a month allows only about 0.43 minutes (26 seconds) of downtime. Any minor blip — a slow deployment, a brief DNS hiccup — can instantly exhaust this budget. The consequence is that product development is perpetually blocked because the error budget is always depleted. SLOs should be set at the level users actually need, not at the maximum theoretically achievable level. Setting aspirational SLOs that cannot realistically be maintained creates organizational friction and makes the error budget framework unworkable. The goal is to find the minimum reliability users find acceptable, preserving budget for innovation.
Question 5: A service has two SLIs: availability (target 99.5%) and latency (target 95% of requests under 300 ms). Error budgets are tracked independently. Which statement is TRUE?
- Exhausting the latency error budget can block releases even if the availability budget still has headroom (Correct answer)
- Only the availability SLO matters for release decisions; latency is advisory
- Both budgets must be combined into a single composite error budget before making release decisions
- Latency SLOs are not measurable as error budgets because latency is a continuous variable
Correct answer: Exhausting the latency error budget can block releases even if the availability budget still has headroom
Each SLO has its own independent error budget. If any budget is exhausted, that dimension of reliability is at risk and release decisions should consider halting risky changes regardless of other budgets.
When a service has multiple SLOs, each carries its own error budget. Exhausting the latency budget signals that the service is too slow for users too often — this is a real reliability problem even if availability is fine. The error budget policy should specify actions for each budget independently. In practice, many teams do combine budgets into a single risk assessment, but the canonical approach is that any exhausted budget should trigger a review and potential release freeze for that dimension. Option B is incorrect because latency directly affects user experience and has clear SLO implications. Options C and D misrepresent how multiple SLOs are tracked.
Question 6: Which technique is MOST effective for reducing measurement noise when calculating SLI compliance for a high-traffic API?
- Use a rolling time window and exclude requests during planned maintenance windows (Correct answer)
- Sample only the first 1,000 requests per hour to keep data volumes manageable
- Calculate SLI compliance based on the slowest 1% of requests only
- Average SLI values across all data centers before comparing to the SLO target
Correct answer: Use a rolling time window and exclude requests during planned maintenance windows
Rolling windows smooth out short spikes and planned maintenance exclusions prevent scheduled work from artificially consuming error budget, both of which reduce measurement noise.
Rolling time windows (e.g., rolling 28 days) smooth out transient spikes that would disproportionately affect a fixed monthly window. Excluding planned maintenance windows is a standard practice — if downtime is announced and users are warned, it should not count against the error budget in the same way an unexpected outage does. Sampling only 1,000 requests/hour introduces bias for high-traffic APIs where millions of requests give a statistically robust measurement. Focusing only on the slowest 1% would measure tail latency, not SLI compliance for the defined SLI. Averaging across data centers can mask regional outages that users in specific regions experience.
SRE Error Budgets & SLI/SLO Management 2
An error budget has been fully consumed three weeks before the end of the quarter.
What is the MOST appropriate response?