# 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.

Source: https://openobserve.ai/glossary/what-is-error-budget/
Published: 2026-07-08
Term: Error Budget
Category: SRE & Incident Response
Related terms: slo-sla-sli, mttr-vs-mttd, what-is-dora-metrics

---

An **error budget** is the amount of failure your [SLO](/glossary/slo-sla-sli/) 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](/blog/slo-based-alerting/) 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

1. Define SLIs and [meaningful SLOs](/blog/set-meaningful-slos/) per service
2. Compute budget consumption continuously from production telemetry
3. Agree the exhaustion policy *before* you need it - what freezes, who decides exceptions
4. 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](/metrics/) and [traces](/traces/), and its [alerting](/alerts/) expresses burn-rate conditions directly - so budget consumption is computed from the same telemetry your incidents are debugged with.