Error Budgets & SLOs: A Complete Guide

"Don't break things" is not a target you can manage — 100% reliability is impossible and chasing it means never shipping. Error budgets replace that fantasy with a number you can actually spend: how much unreliability you'll tolerate over a window, and what happens when you've used it up. Built on SLIs and SLOs, they turn reliability into an explicit, shared trade-off between shipping speed and stability. This guide explains how they fit together and how to run them without a dedicated SRE team.

SLIs, SLOs, and error budgets

Three terms, one idea:

• SLI (Service Level Indicator) — a measurement of how you're doing. For example, the percentage of requests that succeed, or the percentage served under a latency threshold.
• SLO (Service Level Objective) — the target for that SLI. "99.9% of requests succeed over 28 days."
• Error budget — the inverse of the SLO: 100% − SLO. A 99.9% target gives you a 0.1% budget — about 43 minutes of failure per 28 days — that you're allowed to spend.

Pick an SLI that reflects user pain

A good SLI measures something users actually feel. The two most common:

• Availability — successful responses ÷ total responses. Ties directly to the error rate your error tracking already measures.
• Latency — the share of requests served faster than a threshold. Measure it at the P95 or P99 percentile, not the average, because the tail is where users churn.

Choose SLIs at the boundary users touch — the API edge, the checkout flow — not deep internal components. A healthy internal service that still returns errors to users is failing the only SLI that matters.

Set an SLO that's realistic

The instinct is to write "99.99%". Don't — every extra nine is exponentially more expensive, and an SLO you can't meet is just a standing violation everyone ignores. Start from your current measured performance and set the SLO slightly above it. If you're at 99.5% today, target 99.7%, not 99.99%.

Burn rate: spending the budget

The burn rate is how fast you're consuming the budget. Burning it evenly across the window is fine; burning a week's worth in an hour is an incident. This is what you alert on — not every error, but budget burning too fast:

• A fast burn (large fraction of the budget in minutes) pages someone now.
• A slow burn (steady erosion over days) opens a ticket, not a page.

Alerting on burn rate instead of raw error counts is the cleanest way to avoid alert fatigue: you're paged for "we're about to miss the SLO," which is always worth waking up for. It's a sharper version of error alerting best practices.

What happens when the budget runs out

This is the part that makes error budgets real: an error budget policy that everyone agreed to in advance. When the budget is exhausted, the default is to stop shipping features and spend the next cycle on reliability — bug fixes, hardening, paying down the debt that burned the budget. When you're comfortably within budget, you ship freely.

That policy resolves the eternal dev-versus-ops tension with a number instead of an argument. It also gives your error triage a clear priority signal: the issues burning the most budget go to the top of the queue, and lowering MTTR on them directly protects the SLO.

Connect budgets to your error data

Error budgets are only as good as the data feeding them. You need an accurate, deduplicated error rate and per-release visibility to know which deploy is burning budget. Tag every event with a release, watch the crash-free rate per version, and the budget stops being a spreadsheet exercise and becomes a live gauge tied to real production signal. These signals are three sides of the same picture — the logs, metrics, and traces that tell you not just that the budget is burning, but why.

Error budgets won't make your system perfect — that's the point. They make reliability a number you manage on purpose, so you can ship fast when you're healthy and slow down exactly when you need to.