User Journey SLO

A request-level SLI answers "did the server respond successfully". A user journey SLI answers "could the user do the thing they came to do". Those diverge, and the divergence is usually the reason a dashboard is green while customers are unhappy.

The divergence has three independent causes, and any one of them is enough:

Aggregation across request types. Most systems serve far more cheap, frequent requests — polling, telemetry, metadata — than critical ones. If those succeed, the aggregate stays healthy while every attempt at the important operation fails.

Aggregation across users. A failure affecting 2% of users completely looks identical, in aggregate, to one affecting everyone slightly. The first is an outage; the second is imperceptible.

Compounding across a journey. A journey involving twenty requests, each at 99.9%, succeeds about 98% of the time — twenty times worse than the per-request number.

Implementation patterns

• Name the journeys, and keep the list short: sign up, sign in, complete purchase, start playback, send message. Five to ten for most products.
• Measure at the client. A response arriving after the client gave up is recorded server-side as a success. For products used over varied networks, client-side measurement is the only measurement that reflects the product.
• Segment every SLI — by region, device class, network type, tenant size, and by whether the user is in whatever tail concentrates load. Aggregates hide concentrated failure by construction.
• Express the target as the journey's outcome, including latency: "playback starts within N seconds", not "the playback API returned 200".
• Keep the SLO stricter than any SLA, so there is room to react before a contractual event.

Industry example

A live-streaming platform meeting a 99.9% API success target while viewers report the product is unusable is the archetype. The platform's traffic is dominated by frequent low-value calls; the journey that matters — open a stream and watch it — spans many requests, concentrates on the small number of very large streams where load is heaviest, and is experienced entirely at the client.

Restating the SLOs as playback starts within N seconds and the session continues without a rebuffer, measured at the client and segmented by network and stream size, makes the dashboard and the users agree.

The same restatement is what turns SLOs from a reporting exercise into an operational tool: an alert on a journey SLI fires when users are affected, whereas an alert on aggregate request success fires when it is already severe.

Failure scenarios

• Server-side-only measurement, invisible to network and client problems.
• Too many SLOs, so none is treated as binding.
• SLOs on components rather than journeys, which cannot be summed into a user-facing statement.
• Unsegmented aggregates, hiding a regional or device-specific outage.
• SLO equal to the SLA, removing the early-warning function.

Trade-offs

Client-side measurement requires instrumentation you must build, ship and maintain, and it arrives with sampling bias — you only hear from clients that can report. Segmented SLIs multiply the number of metrics and the alerting surface.

The alternative is cheaper measurement of something that is not the question. Given that the entire purpose of an SLO is to represent user experience in engineering decisions, measuring the wrong thing cheaply is a false economy.

Interview question

"Your availability dashboard shows 99.95% and your support queue is full of complaints. Give me three distinct reasons both can be true, and tell me what you would change about the measurement."