Aspirational vs Enforced SLOs

The middle path between "no SLO" and "halt-the-launches SLO" — and when to graduate from one to the other.

Overview

Not every SLO gates launches on day one

The Workbook (Ch 2) explicitly recognizes aspirational SLOs: targets you track but don't enforce. The point is to start measuring, build instrumentation and calibrate the SLI, then graduate to enforcement when the data is trustworthy.

The three stages

1. No SLO — No quantitative reliability target — The starting state for most services
2. Aspirational — Published, measured, dashboarded target; visible budget burn; no policy halts launches — Gather signal and tune the SLI
3. Enforced — Full error-budget policy with halt rules and escalation, signed by SRE, dev and product — Binding reliability contract

Graduation criteria

Trustworthy SLI — Fires on real user-pain incidents and stays quiet on non-issues
Calibrated threshold — Not the absolute max the team hits on a good day, not so loose it never triggers
Three-way sign-off — SRE, dev and product have all signed the policy
Clean burn data — At least one quarter of it

> [!WARNING] Going straight to enforced is a common failure mode. A month-two freeze from an SLI measuring the wrong thing sets dev and SRE against each other, and the policy never recovers credibility.

Key concepts

Aspirational SLO: A target tracked and dashboarded but not enforced — no error-budget policy, no launch halt. Used to validate the SLI implementation before graduating.
Enforced SLO: A target with a binding error-budget policy. Missing it triggers documented consequences (launch halts, postmortems, etc.).
Graduation criteria: When to promote from aspirational to enforced: trustworthy SLI, calibrated threshold, three-stakeholder sign-off, ≥ 1 quarter of clean burn data.
Three corrective paths: When the SLI is wrong (Workbook Ch 2): tighten/loosen thresholds, improve the implementation (measure closer to the user), or downgrade to aspirational while you fix it.

When to use it

Setting up reliability targets for a brand-new service
Building a new instrumentation pipeline (logs/metrics/RUM) — start aspirational while validating
Service has had visible reliability issues but no SRE engagement yet — aspirational gives signal without immediate political cost
Migrating from one SLI implementation to another — keep the new one aspirational until confidence is established

Interview questions

When would you use an aspirational SLO instead of going straight to enforced?
How do you know when to graduate from aspirational to enforced?
My enforced SLO keeps firing on noise. What should I do?