What is an error budget and how does it drive reliability decisions?
Learn what an error budget is, how it equals 100% minus your SLO, and how burn-rate alerting drives ship-vs-freeze reliability decisions in Prometheus.
Expected Interview Answer
An error budget is the amount of unreliability a service is allowed over a period — it equals 100% minus the Service Level Objective (SLO), representing the acceptable failures before users are meaningfully harmed.
If an SLO targets 99.9% availability over 30 days, the error budget is 0.1%, or roughly 43 minutes of downtime. Teams spend that budget on risky deploys, experiments, and incidents. When the budget is healthy, they ship faster; when it is exhausted, they freeze feature work and prioritize reliability. In Prometheus, the budget is computed from SLIs — success/total request ratios — and burn-rate alerts fire when it is consumed too quickly.
- Turns reliability into a shared, quantified budget instead of an argument
- Balances feature velocity against stability objectively
- Enables burn-rate alerting that reflects real user impact
- Aligns product and SRE teams on the same numeric goal
- Prevents both over-engineering and reckless shipping
AI Mentor Explanation
An error budget is like the wickets a batting side can afford to lose while chasing a target. Losing a few early is acceptable and lets batters play aggressively, but once most wickets are gone the tail must play defensively to protect the innings — just as an exhausted budget forces a team to freeze risky releases and bat only for stability.
Step-by-Step Explanation
Step 1
Define an SLO
Set a target such as 99.9% of requests succeeding over a rolling 30-day window, based on user expectations.
Step 2
Derive the budget
Compute error budget as 100% minus the SLO — 0.1% of requests, or the equivalent minutes of downtime, may fail.
Step 3
Measure the SLI
In Prometheus, express the indicator as a ratio like sum(rate(http_requests_total{code!~"5.."}[5m])) / sum(rate(http_requests_total[5m])).
Step 4
Track consumption
Continuously calculate how much of the budget has been spent across the window.
Step 5
Alert on burn rate
Fire multi-window burn-rate alerts (e.g. fast burn over 1h, slow burn over 6h) when the budget is being consumed too quickly.
Step 6
Make decisions
Ship freely with a healthy budget; trigger a change freeze and reliability focus when it is exhausted.
What Interviewer Expects
- Correct relationship: error budget = 100% - SLO
- Understanding of SLI, SLO and SLA distinctions
- How burn-rate alerting reflects budget consumption
- The freeze-vs-ship policy tied to remaining budget
- A concrete Prometheus SLI expression
Common Mistakes
- Confusing SLA (contractual) with SLO (internal target)
- Thinking the goal is 100% reliability rather than meeting the SLO
- Alerting on raw error count instead of budget burn rate
- Never enforcing the freeze policy, making the budget meaningless
- Measuring availability without a defined time window
Best Answer (HR Friendly)
“An error budget is the small amount of failure a service is allowed to have before it disappoints users. Teams use it to decide when it is safe to move fast and ship new features, and when to slow down and focus on fixing reliability.”
Code Example
groups:
- name: slo.rules
rules:
- record: job:request_availability:ratio_rate5m
expr: |
sum(rate(http_requests_total{code!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
- alert: ErrorBudgetFastBurn
expr: |
(1 - job:request_availability:ratio_rate5m) > (14.4 * 0.001)
for: 2m
labels:
severity: page
annotations:
summary: "Burning 30-day error budget too fast (99.9% SLO)"Follow-up Questions
- What is the difference between an SLI, SLO and SLA?
- How do multi-window multi-burn-rate alerts reduce false pages?
- How would you calculate remaining error budget over a rolling window?
- What actions follow when a team exhausts its error budget?
- How do you choose an appropriate SLO target for a new service?
MCQ Practice
1. For a 99.95% availability SLO, what is the error budget?
Error budget = 100% - SLO = 100% - 99.95% = 0.05% of requests may fail.
2. What should burn-rate alerts primarily measure?
Burn-rate alerts fire based on the speed at which the error budget is being spent, reflecting real user impact.
3. When the error budget is exhausted, a common policy is to?
An exhausted budget signals too much recent unreliability, so teams freeze risky work and prioritize stability.
Flash Cards
Define error budget. — The allowed amount of unreliability over a window, equal to 100% minus the SLO.
SLO vs SLA? — SLO is an internal reliability target; SLA is an external contract with consequences if breached.
What is a burn-rate alert? — An alert that fires when the error budget is being consumed faster than sustainable for the window.
What happens when the budget is exhausted? — Teams typically freeze risky changes and shift focus to reliability work.
How is an SLI expressed in Prometheus? — As a ratio of good events to total events, e.g. non-5xx requests divided by all requests.