What are SRE error budgets?

What are SRE error budgets?

• A. A fixed budget of money for deployments.
• B. Allowable reliability shortfall; balance velocity with reliability goals.
• C. A rate limit on feature flags.
• D. A deadline for incident response.

Answer: (B)

Error budgets quantify how much unreliability a service can tolerate while still meeting its reliability targets. They turn the gap between the agreed service level objective (SLO) and actual performance into a budget you can spend. This makes reliability a tangible constraint: if you’re meeting or ahead of your SLO, you have “budget” left to push changes and experiment; if you’re behind, you burn through that budget and should slow down on risky deployments to focus on stability and incident response. Think of it in numbers: if an SLO says 99.9% uptime in a month, that means about 43 minutes of allowed downtime per month. If outages accumulate beyond that, the error budget is spent, signaling that you should curb changes that might introduce more risk until reliability improves. This mechanism explicitly balances velocity (shipping features) with reliability (keeping users up and running). It’s not a fixed monetary budget, not a rate limit on feature flags, and not a deadline for incident response.

Error budgets quantify how much unreliability a service can tolerate while still meeting its reliability targets. They turn the gap between the agreed service level objective (SLO) and actual performance into a budget you can spend. This makes reliability a tangible constraint: if you’re meeting or ahead of your SLO, you have “budget” left to push changes and experiment; if you’re behind, you burn through that budget and should slow down on risky deployments to focus on stability and incident response.

Think of it in numbers: if an SLO says 99.9% uptime in a month, that means about 43 minutes of allowed downtime per month. If outages accumulate beyond that, the error budget is spent, signaling that you should curb changes that might introduce more risk until reliability improves. This mechanism explicitly balances velocity (shipping features) with reliability (keeping users up and running).

It’s not a fixed monetary budget, not a rate limit on feature flags, and not a deadline for incident response.