Module error_budget 

SLIs, SLOs, and Error Budgets

A service level indicator (SLI) measures something users genuinely experience, such as request success rate or latency. A service level objective (SLO) sets a target for that indicator. The error budget is the amount of unreliability the SLO permits — a spendable resource, not something to hoard, that gives both engineering and operations a shared, objective rule for when to ship faster and when to slow down for reliability work.

Formula

Error budget (minutes) = (100 − SLO%) / 100 × period days × 24 × 60
Burn rate               = actual downtime / error budget
Budget exhausted         when burn rate ≥ 1.0

Why it matters

Calculating the error budget directly from the SLO, and tracking spending against it continuously, turns an abstract reliability target into an operational rule: agree in advance, before any specific incident, what happens when the budget is exhausted (a common, effective policy is that feature work pauses and priority shifts to reliability work). This predetermined rule removes the need to relitigate the trade-off under pressure during every individual incident. A healthy, unspent budget is not something to preserve untouched — it is permission to take reasonable, deliberate risks.

Example

The chapter’s own worked example: a 99.9% availability target over 30 days permits roughly 43 minutes of allowed downtime.

use software_engineering::error_budget::{
    error_budget_minutes, error_budget_burn_rate, is_error_budget_exhausted,
};

let budget = error_budget_minutes(99.9, 30.0);
assert!((budget - 43.2).abs() < 1e-9);

// 20 minutes of actual downtime against a ~43-minute budget: not exhausted.
let burn_rate = error_budget_burn_rate(20.0, budget).unwrap();
assert!(burn_rate < 1.0);
assert!(!is_error_budget_exhausted(20.0, budget).unwrap());

Pitfalls

• Setting an aspirational SLO with no evidence behind it — produces a target the team cannot realistically track or act on.
• Treating the error budget as something to preserve rather than spend — a budget that never gets spent suggests an overly conservative team or an SLO set too loosely relative to actual achieved reliability.
• No predetermined response to exhaustion — forces the trade-off to be relitigated under pressure during every individual incident.
• Reviewing SLOs only by inertia, never against evidence of actual achieved reliability or changed user expectations.

Sources

• Chapter 6.1, SLIs, SLOs, and error budgets.

Topic doc: software-engineering-metrics/locales/en-001/chapters/06-01-slis-slos-and-error-budgets.md

Functions

error_budget_burn_rate

How much of the error budget has been spent.

error_budget_minutes

The allowed downtime, in minutes, implied by an availability SLO over a given period.

is_error_budget_exhausted

Whether the error budget is exhausted: burn rate at or above 1.0.