What is an error budget and how does a team use it?
What the interviewer wants to hear
- Error budget is 100% minus the SLO
- Allows some failure because 100% is not the goal
- Balances feature velocity and reliability
- Error budget policy when budget is exhausted
- Shared agreement between dev and SRE
Model answer
The error budget is the amount of failure allowed by the SLO. If the SLO is 99.9% success over 30 days, the budget is 0.1% of requests, or about 43 minutes of full downtime. Because users cannot tell the difference between 99.9% and 100%, we spend that budget on useful risk, such as shipping features and running experiments. The team agrees an error budget policy in advance: while budget remains, releases continue normally; if the budget is used up, we slow or freeze risky launches and spend time on reliability work like fixing the top causes of errors. This turns arguments between developers and operations into a data-driven decision both sides already agreed to.
Can you answer it under time pressure?
Take a timed easy round and get scored on every answer.
More easy Site Reliability Engineer questions
- Explain the difference between an SLI, an SLO and an SLA, with an example.
- What are the four golden signals, and why are they useful for monitoring?
- You are on call and get paged for a high error rate. What are your first steps?
- What is toil, and how would you reduce it on your team?
- What is the difference between monitoring and observability, and what are metrics, logs and traces each good for?
- Why do SRE teams manage infrastructure with code tools such as Terraform instead of clicking in a cloud console?
- Explain blue-green and canary deployments. When would you choose each?
- You are asked to build the main Grafana dashboard for a web API. What would you put on it, and how would you lay it out?
- What makes an on-call rotation healthy and sustainable for the engineers on it?