An error budget is the unreliability your SLO permits. If the SLO is 99.9% over 28 days, the budget is 0.1% of requests, roughly 40 minutes of total downtime. Teams spend it on risky launches, migrations, and experiments. When it is exhausted, the written policy usually freezes feature releases and redirects the team to reliability work until the budget recovers on the rolling window.
Why interviewers ask this
This separates people who have read the SRE book from people who have lived it. The interviewer is checking whether you treat the budget as a decision making tool with a policy attached, rather than a dashboard nobody reads. They also want to hear how you handle the political side, because a release freeze only works if leadership agreed to it in advance and the exception path is defined.
How to structure your answer
- Derive the budget arithmetically from the SLO so it is concrete.
- Say what spends the budget: launches, incidents, migrations, dependencies.
- Describe the written policy that triggers when it hits zero.
- Mention burn rate alerts as the early warning, not the postmortem.
- Name the exception path and who signs it off.
Example answer
The budget is just the inverse of the SLO. At 99.9% over 28 days we had about 40 minutes of full outage equivalent to spend, and we spent it deliberately on things like a database migration or a risky rollout. The important part is the policy, not the number. Ours said that if we burned more than half the budget mid window, canaries got slower and every change needed a second reviewer, and if we hit zero, feature releases stopped and the team worked reliability until the rolling window healed. That was signed off by the product director before we ever needed it, which is the only reason it held the first time we invoked it. We also ran multi window burn rate alerts, a fast one for a 14x burn over an hour and a slow one for a 6x burn over six hours, so we found out during the incident rather than at the end of the month.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- Who can override a release freeze, and what does that cost the team?
- How would you configure multi window burn rate alerts on a 28 day SLO?
- What if the budget is destroyed by a cloud provider outage you do not control?
Related site reliability engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions