# Build SLOs from Critical User Journeys, Not Service Averages

> Define SLOs around critical user journeys like checkout or login so reliability tracks what users actually experience instead of reassuring fleet averages.

Canonical URL: https://www.devobs.io/articles/slo-from-critical-user-journeys/
By: Claire Dubois
Published: 2023-09-21T16:47:16.323Z
Updated: 2026-09-06T08:31:04.426Z
Section: Architecture

Reviewed: 2026-09-06

Start an SLO with one critical user journey and a precise successful outcome. A fleet-wide request average can look healthy while checkout, login, or publishing is broken. The useful question is: of the valid attempts users made at this journey, what fraction completed correctly and fast enough?

## Draw the journey as the user experiences it

Take checkout. The journey begins when an eligible customer submits a valid order and ends when the system returns a durable order identifier with an unambiguous accepted state. Map the synchronous dependencies: edge, checkout API, inventory reservation, payment authorization, and order store. Background email delivery may matter to the product, but it is a separate journey if checkout succeeds before the message is sent.

Define valid attempts before counting success. Exclude requests that never reached your boundary and inputs the contract rejects, such as malformed payloads. Include internal errors, timeouts, dependency failures, and responses that say success without creating the order. Avoid exclusions based on what was convenient during an incident. Google's [SLO implementation workbook](https://sre.google/workbook/implementing-slos/) explains that an SLO sets a target level of reliability for a service's customers and that teams should establish initial SLOs with a process for refining them over time.

## Turn the outcome into an indicator

A request-based checkout indicator might be `good valid attempts / all valid attempts`, where good means an accepted order exists within four seconds and the response identifies it. If a request times out but later creates an order, availability and correctness may disagree: the user saw failure, while a retry risks duplication. Count the experience as failed and track duplicate prevention separately.

Use events that can be joined by a stable journey ID. Edge metrics show what the caller received; application spans show dependency time; business events prove that the durable outcome happened. [OpenTelemetry signals documentation](https://opentelemetry.io/docs/concepts/signals/) says OpenTelemetry currently supports traces, metrics, logs, and baggage as signals, and also notes additional signal types under development or proposal, including profiles. Combining signals is useful, but keep the SLI computable from a small, durable signal set. An SLO that requires an incident investigator to interpret every attempt cannot guide releases.

Aggregation matters. Weighting every pod equally hides a high-volume region; averaging per-minute percentages lets a quiet minute count like peak traffic. Compute the ratio over eligible events, then segment by region, client class, or journey variant to expose concentrated harm. Keep the contractual SLO simple and use segments as diagnostic and guardrail views.

## Set an objective that changes decisions

Choose the initial target from user tolerance, historical performance, and the cost of improvement. Write the window and error budget explicitly: for example, 99.9% successful valid checkout attempts over 28 rolling days. Google's [SLO implementation workbook](https://sre.google/workbook/implementing-slos/) explains that organizations need approved SLOs, a formalized error budget policy, and a process for refining the SLO if they want error budgets to drive prioritization rather than remain a reporting metric. For related alerting tactics, see [our guide to multi-window burn-rate alerts](https://www.devobs.io/articles/multi-window-burn-rate-alerts/).

Then define what budget consumption changes. A rapid burn can page; sustained burn can pause risky releases; a healthy budget can support planned changes.

Do not silently reset the measurement when telemetry fails. Missing events are a data-quality incident. Compare the denominator with independent request counts and alert on discontinuities. Also assign one owner for the journey even though several teams own dependencies. The journey owner coordinates the objective; dependency teams own their contributing signals and fixes.

## Test the definition with ugly cases

Walk through payment declines, inventory conflicts, client disconnects, duplicate submissions, partial regional outages, and a dependency returning syntactically valid nonsense. Decide whether each attempt is eligible and good before implementation. If two engineers classify the same case differently, the SLI is underspecified.

Retry accounting also needs a journey key. If the first attempt times out and a retry succeeds, request metrics can report both failure and success while the customer experienced one uncertain action. Join attempts before evaluating the result, and track ambiguity as its own diagnostic signal.

The next step is to pick the single journey that creates the most painful support tickets. Sample 100 recent attempts, label them by the proposed rules, and compare the resulting SLI with what users reported. Review the journey definition quarterly or after a material journey change.

## Source references

- <https://sre.google/workbook/implementing-slos/>
- <https://opentelemetry.io/docs/concepts/signals/>