SLOs that actually drive decisions (not just dashboards nobody reads)

TL;DR

• Most SLOs fail for the same reason: nobody has decided what happens when they’re breached. A target with no consequence is a wish, not an SLO.
• The fix is to write the policy before the number — what changes when the error budget is exhausted, and who has the authority to enforce it.
• Good SLOs are few (3-5 per service, not 30), tied to what the user actually experiences, and reviewed on a cadence that matches how fast your error budget actually burns.
• The test of a real SLO: can you point to a specific decision — a delayed release, a reprioritized sprint, a postponed feature — that it caused in the last quarter? If not, it’s a dashboard, not an SLO.

The problem: SLOs that decorate dashboards instead of driving anything

Walk into almost any engineering org with “mature” observability, and you’ll find a Grafana dashboard with SLO panels — 99.9% availability, 99.95% success rate, p99 latency under 300ms — sitting green, month after month, changing nothing about how the team works.

That’s not maturity. That’s theater.

The tell is simple: ask “what happens when this SLO is breached?” If the honest answer is “someone gets a Slack notification and we discuss it at the next retro, maybe,” you don’t have an SLO — you have a number with a target attached. A real SLO has teeth: it changes what the team does next, automatically or by clear policy, the moment the error budget runs out.

This matters because the entire point of SLOs is to convert a fuzzy, political argument — “should we fix this bug or ship this feature?” — into a data-driven one. If the SLO doesn’t actually settle that argument when it comes up, it has failed at its one job.

The framework: write the policy before the number

Step 1: Pick the few things users actually feel

Start from the user’s experience, not your architecture. For most services, that’s three to five SLIs maximum:

• Availability — can the user complete the core action (log in, load the page, complete the transaction)?
• Latency — does it feel fast at the percentile that matters (usually p95 or p99, not average — averages hide the worst experiences)?
• Correctness — did the user get the right answer/result/data?

Resist the urge to SLO everything that’s measurable. CPU utilization, queue depth, and cache hit rate are useful operational signals — they are not SLOs, because the user doesn’t experience them directly. An SLO list with thirty entries is a sign that nobody has done the hard work of deciding what actually matters.

Step 2: Set the target from data, not aspiration

“Five nines” is not a target — it’s a slogan. The right target comes from two inputs: what your users actually need (a B2B analytics dashboard and a payment authorization API have very different latency tolerances), and what your current baseline actually is. Setting a target meaningfully tighter than your last six months of real performance just guarantees a permanently exhausted error budget — which trains the team to ignore it.

Step 3: Write the consequence — this is the step everyone skips

This is the part that turns a number into an instrument. Before you publish the SLO, answer in writing:

• When the error budget is at 25% remaining, what changes? (Common answer: feature work continues, but reliability work gets equal priority in planning.)
• When the error budget is exhausted, what changes? (Common answer: feature releases pause; the team’s next sprint is reliability-only, until the budget recovers.)
• Who has the authority to invoke — and to override — that policy? (Usually: the service owner can invoke it; overriding it requires a director-level conversation, on the record.)

Without this step, the SLO is advisory, and advisory reliability targets lose every negotiation against a roadmap deadline. With it, “we’re at 40% error budget remaining, so this feature ships next sprint instead” stops being an argument and starts being a process.

Step 4: Review on a cadence that matches your burn rate

A service with a tight latency SLO and bursty traffic can exhaust a monthly error budget in an afternoon — reviewing it monthly means you find out four weeks too late. A stable, low-traffic internal service can be reviewed quarterly without missing anything. Set the review cadence based on how fast the budget can burn, not on a calendar default.

Real-world example

A fintech client had eleven services, each with an availability SLO, each sitting at “healthy” on a dashboard nobody had opened in six weeks. When we asked what would happen if one breached, the answer was “I think we’d talk about it.” That’s not a policy — that’s a hope.

We rebuilt their SLOs around three SLIs per service (availability, p99 latency, transaction-correctness rate), set targets from twelve months of real data rather than round numbers, and — critically — wrote an explicit error-budget policy: below 50% remaining, reliability work gets equal sprint priority; at 0%, feature releases pause until the on-call lead and the service owner jointly sign off on a recovery plan.

Eight weeks later, that policy did exactly what it was designed to do: a payments service burned through its budget after a vendor API started intermittently timing out. The team paused a planned feature release — a decision that, six months earlier, would have triggered a multi-week argument between product and engineering — and resolved the underlying issue in four days. The policy made the call. Nobody had to win an argument.

Trade-offs and what we’d avoid

• Don’t SLO every service equally. A service that fails open with no user impact doesn’t need the same rigor as one on the critical path. Spend the policy-writing effort where the consequences of breach are real.
• Don’t set the target before you have a baseline. A target chosen before you’ve measured reality is a guess wearing a lab coat. Measure first, even if it takes a month.
• Don’t let the error-budget policy live only in a wiki page. If invoking it requires someone to remember it exists and dig it up mid-incident, it won’t get invoked. Bake the threshold into the alerting and the planning ritual itself.

What to do next

1. Pick one service and ask the question out loud: “what happens when this SLO breaches?” If the room doesn’t have a confident, specific answer, that’s where to start.
2. Write the error-budget policy before you touch the dashboard. The number is the easy part; the policy is the part that makes it real.
3. Talk to us about an SRE practice review — our SRE Consulting engagements typically start with exactly this exercise: turning a wall of green dashboards into a small number of SLOs that actually govern decisions, plus the on-call structure to back them. If you need ongoing coverage rather than a one-time review, our 24×7 Managed SRE team operates against the SLOs we help you define.

If your team has SLOs that nobody can point to a decision they’ve caused, book a 30-minute call — we’ll walk through what we’d look for first.

Related reading: Running vLLM on EKS — a production checklist for a worked example of SLIs that matter for AI-serving workloads specifically.