SLOs That Actually Work

Everyone knows they should have SLOs. Far fewer teams have SLOs that change how they behave. Here’s how I think about making them real.

Start with the user, not the system

A good SLO measures something a user actually feels. “CPU under 80%” is a system metric — nobody outside your team cares. “99.9% of checkout requests succeed in under 300ms” is a user experience.

Ask: what does ‘working’ mean to the person on the other end?

The three ingredients

Every SLO needs:

An SLI — the thing you measure (e.g. request success rate).
A target — the threshold (e.g. 99.9% over 30 days).
An error budget — what’s left over (0.1% = ~43 minutes/month of allowed failure).

error_budget = 1 - SLO_target
99.9% target  →  0.1% budget  →  ~43m / 30 days
99.95% target →  0.05% budget →  ~21m / 30 days

Error budgets are the whole point

The target isn’t there to be hit perfectly — it’s there to give you a budget to spend. When there’s budget left, ship fast. When it’s exhausted, slow down and stabilize.

An SLO without an error-budget policy is just a dashboard nobody looks at.

Common mistakes

Too many SLOs. Start with one or two per critical journey.
Targets too high. 100% is a trap — it removes your budget for change.
No consequences. If blowing the budget changes nothing, it’s decoration.

Where to go next

Once you’ve got one working SLO with an agreed policy, expand slowly. Reliability is a practice, not a config file.

More on error-budget policies in a future post.