How is an error budget calculated?

Error budget = 1 − SLO target, applied over the SLO window. A 99.9% availability SLO over 28 days allows 0.1% failure - about 40 minutes of full downtime, or the equivalent spread across partial degradations. Consumption is tracked as the fraction of that allowance already used.

Burn rate is how fast you are consuming error budget relative to the sustainable pace. A burn rate of 1 exactly exhausts the budget at the window's end; a burn rate of 14 exhausts it in two days. Multi-window burn-rate alerts (fast burn pages, slow burn tickets) are the standard SLO alerting pattern.

What happens when the error budget is exhausted?

The classic policy freezes risky changes - feature releases pause and engineering shifts to reliability work until the budget recovers. The specifics matter less than agreeing on consequences in advance, so the reliability-vs-velocity negotiation is automatic rather than political.

What is an Error Budget?

An error budget is the amount of unreliability an SLO permits — if your target is 99.9%, the 0.1% is budget you can spend on releases, experiments, and maintenance before halting risk.

SRE & Incident Response Last updated: July 8, 2026

An error budget is the amount of failure your SLO allows. If you promise 99.9% availability over 28 days, then 0.1% — roughly 40 minutes — is budgeted unreliability. The reframing is the point: perfection is not the goal, and the gap between your target and 100% is a resource to be spent deliberately on the things that cause failures — deployments, migrations, experiments, dependency upgrades.

Why error budgets exist

Error budgets resolve the oldest conflict in operations: developers want to ship fast, operators want stability. Without a shared number, that conflict is settled by politics and post-incident blame. With one:

Budget remaining → ship freely; the system is reliable enough to absorb risk
Budget exhausted → releases pause; engineering effort shifts to reliability until the budget recovers

Reliability and velocity stop being opposing values and become one negotiated quantity.

Burn rate: the operational metric

Day to day, teams watch the burn rate — how fast budget is being consumed relative to the sustainable pace. Burn rate 1 means you’ll land exactly on target; burn rate 14 means a 28-day budget dies in two days. The standard SLO alerting pattern uses multi-window burn-rate alerts: a fast burn (14x over 1 hour) pages immediately, a slow burn (2x over 6 hours) opens a ticket. This replaces noisy threshold alerts with alerts that fire precisely when user-facing reliability is genuinely at risk.

Making budgets real

Define SLIs and meaningful SLOs per service
Compute budget consumption continuously from production telemetry
Agree the exhaustion policy before you need it — what freezes, who decides exceptions
Review budget spend in planning: repeated exhaustion means invest in reliability; chronic surplus may mean you can ship more aggressively (or your SLO is too loose)

Error budgets in OpenObserve

OpenObserve tracks SLI ratios from your metrics and traces, and its alerting expresses burn-rate conditions directly — so budget consumption is computed from the same telemetry your incidents are debugged with.

Frequently asked questions

: Error budget = 1 − SLO target, applied over the SLO window. A 99.9% availability SLO over 28 days allows 0.1% failure - about 40 minutes of full downtime, or the equivalent spread across partial degradations. Consumption is tracked as the fraction of that allowance already used.
: Burn rate is how fast you are consuming error budget relative to the sustainable pace. A burn rate of 1 exactly exhausts the budget at the window's end; a burn rate of 14 exhausts it in two days. Multi-window burn-rate alerts (fast burn pages, slow burn tickets) are the standard SLO alerting pattern.
: The classic policy freezes risky changes - feature releases pause and engineering shifts to reliability work until the budget recovers. The specifics matter less than agreeing on consequences in advance, so the reliability-vs-velocity negotiation is automatic rather than political.

Keep reading

Back to Glossary