TPL-21Reliability

SLO Definition Worksheet

SLOs only work when they represent something a user would notice. Define them from the outside-in — the top 3 user journeys — not from whatever's easy to measure.

The user journey

Name the journey in user language: 'complete a purchase,' 'load the dashboard,' 'authenticate.' Not 'API endpoint /v2/foo.'

The SLI

A precise, measurable indicator: 'p99 latency of the purchase-complete request,' 'success rate of login over 5-minute windows.' Write the exact query.

The SLO

Threshold: e.g., 99.9% of requests succeed
Window: rolling 28 days is a good default
How you'll know you missed it (dashboard, alert)

Error budget policy

What happens when you burn through the budget? Freeze on non-reliability work, or explicit trade-off with product. Written before it happens, not during.

Common pitfalls

— SLOs at 100%. That's not an objective; that's a promise you'll break.
— SLIs no user could recognize. Fix the SLI before you tune the SLO.
— No error budget policy. Then the SLO is just decoration.

One practical engineering leadership lesson every week.

Get one useful idea you can apply with your team — a framework, conversation technique, template, or lesson from real engineering leadership.

Trouble seeing the form?Get the Next Issue →

Free. Useful. No motivational fluff.