Critical User Journeys

How to find what to actually measure — the multi-step user task whose end-to-end success defines the service.

Overview

Measure the journey, not the call

An SLO measured at the wrong layer is worse than no SLO. A service can hit 99.99% on individual API calls while 30% of user checkouts fail, because the calls compose into a path that breaks somewhere in the middle. What matters is the end-to-end user task.

> [!IMPORTANT] The Workbook (Ch 2) defines the Critical User Journey (CUJ) as "a multi-step user task whose end-to-end success is what really matters."

CUJ examples

E-commerce — "Complete a checkout" — "API responds 200 on individual route"
Streaming — "Start watching this title within 5 seconds of clicking play" — "Metadata service responds"

From CUJ to SLI

Once you have the CUJ, the SLI takes the canonical good/total form: successful CUJ completions / valid CUJ attempts over a window. That ratio is the actual user-visible reliability.

The SLI menu by service type (Workbook Ch 2)

Request-driven — Availability, latency, quality
Pipeline — Freshness, correctness, coverage
Storage — Durability

> [!TIP] Pick the dimension that maps to your CUJ's success criterion. A 200 OK with the wrong content is still an error if wrong content is what the user noticed.

Key concepts

Critical User Journey (CUJ): A multi-step user task whose end-to-end success is what really matters. e.g. "complete a checkout," "play a video within 5s," "load a feed under 2s."
Good / total form: Canonical SLI shape: ratio of successful events to all valid events over a window. e.g. successful_checkout_completions / valid_checkout_attempts.
SLI specification vs implementation: Specification = what users care about (measurement-independent). Implementation = how you actually measure it (specification + how you collect data). Write the spec first; pick the implementation second.
SLI menu by service type: Request-driven: availability + latency + quality. Pipeline: freshness + correctness + coverage. Storage: durability.
Quality SLI: "200 OK with the wrong content" still counts as a failure if the wrong content is what the user noticed. Quality is the often-missed dimension.

When to use it

Designing the SLI for a new service — start from the CUJ, not from the API surface
Diagnosing an SLO that's green while users are unhappy — the SLI is at the wrong layer
Picking which dimension to SLO (availability vs latency vs quality vs durability)
Reviewing a service's SLO suite — does it actually cover the user's end-to-end experience?

Interview questions

What's a Critical User Journey and why does it matter for SLO design?
Walk me through SLI specification vs implementation.
Quality is in the SLI menu but most teams skip it. Why does it matter?