We've watched several SLO initiatives die the same death: a working group defines forty objectives in a spreadsheet, dashboards get built, a quarter later nobody can name a single SLO and the pager is as noisy as ever. The failure isn't the idea. It's starting with coverage instead of consequence.
Start with journeys, not services
Service-level objectives fail when they're defined per service: every team dutifully picks 99.9% availability for their microservice, and nobody can say what any of it means for a user. Start from the other end. Pick the three or four journeys where failure costs you:
- Can a user sign in?
- Can they see their data?
- Can they check out?
- Does the async thing they triggered finish?
Each journey gets one availability SLO and one latency SLO, measured as close to the user as your telemetry allows. That's it. Eight numbers, not forty.
Wire alerts to burn rate, delete the rest
An SLO you don't alert on is a dashboard decoration. The standard multi-window burn-rate pair is enough:
# Page: at 14.4x burn, a 30-day budget is gone in ~2 days
- alert: CheckoutAvailabilityFastBurn
expr: slo:burn_rate:1h{journey="checkout"} > 14.4
and slo:burn_rate:5m{journey="checkout"} > 14.4
# Ticket: slow leak, handle in business hours
- alert: CheckoutAvailabilitySlowBurn
expr: slo:burn_rate:24h{journey="checkout"} > 3
Then the hard part: every cause-based alert that pages a human gets reviewed against one question. If this fires and the SLOs are fine, do we care at 3 a.m.? In most environments this deletes or downgrades the majority of pages. That deletion, more than anything, is what buys engineer trust.
One ritual, twenty minutes
Skip the error-budget policy document for now. Institute a single ritual: twenty minutes, every other week, per team. Look at each SLO, its remaining budget, and the pages since last time. Three outcomes are allowed: do nothing, adjust the objective because it was wrong, or pull one reliability item into the next sprint. The meeting exists so the numbers have consequences; the numbers exist so the meeting stays short.
What to postpone
Error-budget freezes, SLOs for internal services, executive scorecards, tooling migrations: all of it can wait until the basic loop (measure journeys, alert on burn, review budgets) has run for a quarter and people believe it. SRE adoption is a trust exercise wearing a math costume. Earn the trust with a quieter pager first; the ceremony can come later, if you still want it.
What this looks like as an engagement: the on-call reset scenario.