What is an Error Budget?
Learn what an error budget is, how it is calculated from an SLO, and how it governs release risk decisions in DevOps teams.
Expected Interview Answer
An error budget is the allowed amount of unreliability a service can accumulate before breaching its SLO, calculated as 100% minus the SLO target over the measurement window, and it gives teams an objective, data-driven way to decide how much release risk they can take on right now.
If a service has a 99.9% availability SLO over 30 days, the error budget is the remaining 0.1%, which translates to roughly 43 minutes of allowed downtime or failed requests in that window. As long as budget remains, the team can ship features, run experiments, and take calculated risks with deployments, because some failure is already accounted for. Once the budget is exhausted, the standard policy is to freeze risky releases and redirect engineering effort toward reliability work — fixing the root causes that burned the budget — until the service is back within its target. This mechanism replaces subjective arguments between product and engineering about “is it safe to ship” with an objective number both sides agree to in advance, and burn-rate alerts (how fast the budget is being consumed relative to the time window) give early warning before the budget is fully gone.
- Replaces subjective release-safety debates with an objective, shared number
- Balances feature velocity against reliability using real data
- Triggers an automatic policy shift to reliability work when exhausted
- Burn-rate tracking gives early warning before the budget runs out
AI Mentor Explanation
An error budget is like a bowler’s allowed quota of overs for risky, aggressive short-pitched bowling in a Test match before the umpire and captain rein it in. As long as that quota remains, the bowler can keep attacking with bouncers and risk being hit for boundaries occasionally. Once the quota is used up, the captain shifts the bowler to safer, defensive lines to protect the team’s position. The quota gives an objective number for how much risk is still affordable, rather than a subjective argument every over.
Step-by-Step Explanation
Step 1
Calculate the budget
Subtract the SLO target from 100% over the measurement window to get the allowed unreliability.
Step 2
Track consumption
Continuously measure the SLI against the budget, monitoring burn rate in real time.
Step 3
Ship freely while budget remains
Teams take calculated risks with releases and experiments as long as budget is available.
Step 4
Freeze and remediate when exhausted
Halt risky releases and prioritize reliability fixes until the service returns within its SLO.
What Interviewer Expects
- Understanding of how an error budget is calculated from an SLO
- Awareness that budget remaining governs release risk decisions
- Knowledge of what a policy freeze on budget exhaustion means in practice
- Ability to explain burn-rate as an early-warning signal
Common Mistakes
- Confusing an error budget with uptime itself rather than allowed unreliability
- Not tying budget exhaustion to a concrete release-freeze policy
- Forgetting the budget resets or rolls over a defined time window
- Treating the error budget as a punishment rather than a planning tool
Best Answer (HR Friendly)
“An error budget is simply the amount of unreliability we are allowed before breaching our internal reliability target. If we still have budget left, we can ship new features and take reasonable risks. If we have used it all up, we pause risky releases and focus the team on fixing reliability first. It turns “is it safe to ship this week” into an objective number everyone already agreed on, instead of a debate.”
Code Example
# SLO target: 99.9% over a 30-day window
# Total minutes in window
TOTAL_MIN=$((30 * 24 * 60))
# Allowed downtime minutes (the full budget)
BUDGET_MIN=$(echo "$TOTAL_MIN * 0.001" | bc)
# Minutes already consumed this window (from monitoring)
CONSUMED_MIN=18
echo "Budget remaining: $(echo "$BUDGET_MIN - $CONSUMED_MIN" | bc) minutes"Follow-up Questions
- How do you calculate error budget from a given SLO percentage?
- What should a team do once its error budget is fully consumed?
- How does burn-rate alerting relate to the error budget?
- How would you present an error budget policy to a non-technical stakeholder?
MCQ Practice
1. How is an error budget calculated?
The error budget is the allowed unreliability, calculated as the gap between 100% and the SLO target.
2. What typically happens when a team fully exhausts its error budget?
Standard error-budget policy freezes risky feature releases and redirects engineering focus to reliability fixes.
3. What does “burn rate” measure in the context of an error budget?
Burn rate tracks how fast the error budget is being consumed, giving early warning before it is fully exhausted.
Flash Cards
What is an error budget? — The allowed unreliability before breaching an SLO, equal to 100% minus the SLO target.
How is it used operationally? — Remaining budget allows risky releases; exhausted budget freezes releases for reliability work.
What is burn rate? — How fast the error budget is being consumed relative to the measurement window.
Main benefit of error budgets? — They replace subjective “is it safe to ship” debates with an objective shared number.