What is an error budget and how is it used?

WHAT THIS TESTS Whether you understand that 100 percent reliability is the wrong target and that an error budget operationalizes a deliberate, shared tolerance for failure to balance velocity against stability.

A GOOD ANSWER COVERS The error budget is the maximum amount of unreliability the service is allowed over the SLO window, computed as 100 percent minus the SLO. If the auth SLO is 99.95 percent availability over 28 days, the budget is 0.05 percent of valid requests, the allowed failures. The team monitors burn rate, how quickly the budget is being consumed, and uses it as a control signal. When budget remains, they can ship features, run migrations, and take measured risks, even using chaos experiments, because some failure is acceptable. When the budget is exhausted or burning too fast, an agreed error-budget policy takes effect: freeze risky feature launches, and redirect engineering effort to reliability, hardening, bug fixes, and toil reduction, until the service is back within budget. This aligns developer and SRE incentives around one number instead of arguing about whether to ship. Fast-burn and slow-burn alerts catch both sudden incidents and gradual erosion.

COMMON WRONG ANSWERS Treating the goal as maximizing uptime, which wastes the budget and slows delivery. Thinking the budget is a target to spend down deliberately for its own sake. Having no policy for what happens when it is exhausted. Ignoring burn rate and only checking at the end of the window. Confusing it with an SLA penalty.

LIKELY FOLLOW-UPS What is a burn-rate alert. What goes in an error-budget policy. Who decides to enforce a freeze. How do you reset the budget across windows.

ONE CONCRETE EXAMPLE With a 99.95 percent monthly SLO, the auth team has a small budget of allowed failures. Early in the month a bad deploy spikes errors and burns 60 percent of the budget in a day, tripping a fast-burn alert. They roll back and continue shipping cautiously. Two weeks later, after another incident exhausts the budget, the error-budget policy triggers a feature freeze, and the team spends the rest of the month on reliability fixes until the rolling SLI recovers above target.