Error Budgets in SRE: How to Set, Measure, and Enforce Them

You can balance release velocity with reliability by setting an explicit allowance for failure rather than chasing 100 percent reliability. With Site Reliability Engineering (SRE), you use that allowance to decide when to ship and when to stabilize.

This guide covers how you set the budget from a Service Level Objective (SLO), measure its burn rate with alerts, and enforce a written policy when it runs low.

What Is an Error Budget?

An error budget is the amount of unreliability your service may accumulate over a measurement window without missing its SLO. The error budget is “one minus the availability target.” Every failed request, slow response, or minute of downtime inside the window draws that budget down. Reliability becomes a spending limit for your release decisions.

The concept came out of Google’s SRE practice as a way to settle the standing conflict between product development, measured on velocity, and SRE, measured on reliability. Putting a number on remaining budget “removes politics from risk negotiations,” because you spend less time debating whether a launch is too risky when your dashboard shows how much room is left. A tighter internal SLO than the one advertised to users “gives you room to respond to chronic problems before they become visible externally,” so your budget forces action before any contractual penalty applies. That buffer depends on how your SLI, SLO, and SLA relate.

How Error Budgets Relate to SLIs, SLOs, and SLAs

A Service Level Indicator (SLI) is the measured signal, such as the fraction of requests returning a 2xx status. The SLO is the target you set for that signal over a window, and the error budget is the remainder up to 100 percent. A Service Level Agreement (SLA) comes last and belongs to the business rather than to SRE; it is a contract whose consequences, including financial ones such as a rebate or a penalty, attach to the SLOs inside it.

For a payment service, your SLI is the ratio of successful payment requests to total requests, and your SLO leaves a small fraction of requests available as an error budget. The merchant contract promises a looser objective than your internal SLO. When your internal budget runs out, you’ve missed your own target, but still have some slack before anyone owes a refund, which is why you alert on the budget and not on the SLA.

How to Calculate Your Error Budget

A time-based error budget counts minutes of downtime and suits services that are either up or down; a request-based error budget counts failed events and suits partial outages. You apply the remaining fraction to the window’s minutes or total requests. The table shows the allowed downtime and failed requests for three common targets:

SLO target	Error budget	Allowed downtime per 30 days	Allowed failures per 1,000,000 requests
99.9%	0.1%	43.2 minutes	1,000
99.95%	0.05%	21.6 minutes	500
99.99%	0.01%	4.32 minutes	100

A calendar window resets on a fixed date, and your team may freeze changes near month-end to avoid ending the month in the red. A rolling window recomputes over the trailing 30 days, and your rolling error budget regains room as old bad minutes age out. You can use rolling windows to reduce sensitivity to when an outage lands.

Burn Rate: Measuring How Fast You’re Spending Your Budget

Error budget burn rate is how fast your service spends its error budget relative to its SLO. A burn rate of one leaves you with no budget at the end of the SLO’s time window, while a higher rate exhausts it before the window ends. Fast burns come from sudden spikes, such as a deploy that fails a large share of requests and can empty your budget within hours. A degraded dependency can cause a slow burn through a low, steady error rate that exhausts your budget over days. You need a short lookback to page someone within minutes for the first case and a long lookback that smooths noise and justifies a ticket for the second.

How to Pair Burn-Rate Alert Windows

Multiwindow, multi-burn-rate alerting combines short and long lookbacks to catch both sudden spikes and steady degradation. The table shows starting values for the first SLO target in the calculation table. Each long window is paired with a short window one-twelfth its length. An alert fires only when both windows exceed the threshold. The short window lets the alert stop firing soon after the problem ends, while the lower-threshold tiers catch steady burn that a single high threshold would ignore. Together, these settings separate useful paging from alert fatigue.

Response	Burn rate	Long window	Short window	Budget consumed
Page	14.4×	one hour	five minutes	two percent
Page	six×	six hours	30 minutes	five percent
Ticket	one×	three days	six hours	10%

How SRE Teams Use Error Budgets in Practice

You use the budget to decide, with less debate, whether to ship or stabilize. While budget remains, your developers can launch features and take risky deploys; once your team spends it, changes freeze, with exceptions for urgent security fixes and other highest-priority issues your policy permits, until your service earns budget back or the window resets. When your service runs well within its SLO, you should spend the spare budget on feature velocity, with extra testing or canary analysis as the budget drops and a freeze reserved for near-exhaustion. Your policy also needs to address whether planned maintenance spends that budget.

Planned maintenance can draw from the same budget, so decide how your maintenance window error budget works up front. Your policy should “Treat maintenance as downtime” when your team intends to reduce it; if the policy defines no consequences, a recurring window nobody plans to shrink becomes a burn nothing prioritizes fixing. A badly chosen SLO shows up in the budget too: a team that never approaches exhaustion may be over-investing in reliability. If a 50 percent overspend lines up with a one percent drop in revenue, relaxing the SLO to 99.5 percent may cost less than the engineering needed to hit the original.

Enforcing Your Error Budget: Policies and Escalation

An error budget policy is a written agreement naming who does what when your budget crosses each threshold. Your product manager, development team, and SRE approve it before enforcement. They test whether the SLOs are fit for purpose and establish that the policy isn’t a punishment. One example halts all changes other than the highest-priority P01 issues or security fixes once your team exceeds its four-week budget. It also requires a postmortem with at least one P0 action item for any single incident consuming more than 20 percent of the budget. Signing it while your budget is healthy gives a later freeze its authority.

How to Escalate Before Exhaustion

Your policy can add graduated responses before exhaustion and keep code frozen until enough budget recovers and all alerts clear. An incident large enough to trigger the postmortem rule also gets a root cause analysis with owned action items. You can define escalating responses as follows:

• Early consumption: Your team notifies engineering leads about the burn.
• Rising consumption: Your team engages incident response.
• Near-exhaustion: Your team considers a feature freeze.
• Exhaustion: Your team begins an all-hands response, and changes halt under the policy above.

Which Policy Mistakes to Avoid

SLO selection and traffic patterns can also undermine your policy. These mistakes can leave your team frozen or produce misleading burn-rate alerts:

• Failure scorecard: Treating the budget as a failure target discourages deliberate spending on releases.
• Unreachable SLO: Setting a target your service can’t realistically meet leaves your team permanently frozen.
• Seasonal variation: A budget sized on quiet months drains fast during holiday peaks, while weekend lulls make burn-rate alerts noisy because a few failures swing the ratio.

How to Keep Error Budgets Accurate as Services Change

Your SLO should come from user pain rather than a round number, which is why an SLI on checkout success beats one on CPU load. Observability platforms with built-in SLO tracking, such as Coralogix’s SLO Center, replace a manual spreadsheet with continuous burn-rate alerts. Review targets monthly while an SLO is new and quarterly once it settles, and agree the schedule with product before incidents.

Services that depend on each other need composite budgets, because a user journey fails when any link in it fails. A composite SLO “burns its error budget when any of SLOs beneath burns their error budget,” with each component’s weight multiplying its contribution. Weights should follow user impact, so a payment failure in a checkout journey counts for more than a failed review submission.

Closing the Loop Between Setting, Measuring, and Enforcing

Setting, measuring, and enforcing work as one loop. If you don’t measure the budget continuously, you discover it at exhaustion; if you don’t sign the policy in advance, you renegotiate it during the incident it was meant to govern. Coralogix’s SLO Center tracks error budgets centrally across services and alerts on error budget or burn rate before an SLO breach reaches customers, so you can enforce the policy without a manual review calendar.

Frequently Asked Questions About Error Budgets

Your SLO sets the budget you can spend. Burn-rate alerts show how quickly you’re spending it. Your written policy determines how your team responds as it runs low, from notifying engineering leads to halting changes at exhaustion.

What Is the Concept of an Error Budget?

An error budget is the unreliability your service can accumulate over a defined period while still meeting its SLO. Google’s SRE practice popularized it as a resource you spend deliberately rather than a pass/fail goal.

How Do You Calculate an Error Budget?

You get the error budget by subtracting the SLO target from full reliability and applying that fraction to your window, either minutes of downtime or counted requests. The calculation table shows common targets. Your SLI determines whether you count downtime or failed requests.

What Is the Difference Between SLI, SLO, and Error Budget?

The SLI is your metric, the SLO is the target you set for it over a window, and the error budget is the remaining allowance for failure. You can spend that headroom on failures, risky releases, and planned maintenance.

What Happens to Feature Development When an Error Budget Is Exhausted?

When you exhaust your error budget, you freeze feature releases until the window resets or enough budget recovers and all alerts clear, with exceptions for security fixes and the highest-priority bugs. The policy that product, development, and SRE approved beforehand should already say who can lift the freeze and revisit policy mistakes that keep your team frozen.

What Are the Most Common Mistakes Teams Make With Error Budgets?

An SLO that’s too loose or too tight for your service’s real mean time to repair can undermine your budget. Treating the budget as a failure scorecard or ignoring traffic swings between peak seasons and quiet periods can also undermine it; use the budget as a spending limit. Decide separately how to account for planned maintenance, and count it as downtime when your team plans to reduce it. These fixes start with revisiting the SLO or the policy with the people who approved it. If you want to see your own services’ remaining budget, start a free 14-day Coralogix trial and define SLOs for them.