Defining Measurable Service-Level Indicators for User Journeys

Welcome back. In the previous lesson, you learned to classify an incident by the user promise it breaks: availability, latency, correctness, or durability. That tells us what kind of harm occurred. Now we make that impact measurable.

This lesson focuses on turning a user journey into a service-level indicator (SLI): a precisely defined measurement of whether users received the service outcome that matters. We will use a mail application’s send mail journey as the worked example, while building a method you can reuse for checkout, login, file upload, API calls, or internal platform services.

---

An SLI measures a user-relevant outcome

An SLI is not simply any metric displayed on a dashboard. CPU utilization, Pod count, queue depth, and database connections can all be valuable operational signals, but none directly answer: did the user successfully accomplish the thing they came to do?

A practical SLI is usually expressed as a ratio:

$$\text{SLI}=\frac{\text{good eligible events}}{\text{all eligible events}}\times 100\%$$

This form forces two decisions:

1. What counts as an event?
2. What makes that event good?

For a request-driven service, an event may be an HTTP request. For an asynchronous workflow, it may be a confirmed job submission. For storage, it may be a previously written object that can still be read successfully.

Keep these terms distinct:

Term	Meaning	Example
User journey	A meaningful sequence of actions with a user goal.	“Send an email message.”
SLI specification	The user-centered definition of the outcome to measure.	“A valid send request is accepted durably within two seconds.”
SLI implementation	The concrete telemetry, query, and measurement point used to calculate it.	Gateway logs plus an application event that confirms durable acceptance.
SLO	The target value expected for an SLI over a stated time window.	This comes later; it is not the SLI itself.

The distinction between specification and implementation is especially important in SRE work. You might agree that a page must load quickly for real users, but measure it from server logs, a load balancer, synthetic probes, or browser instrumentation. Each implementation sees a slightly different version of the experience.

---

Begin with a critical user journey, not a component

A critical user journey is a task essential to a user and to the product or business. It is a better starting point than infrastructure boundaries such as “the Kubernetes cluster is healthy” or “the database is up.”

The mail application flow below illustrates the difference. A user’s objective is not “call the Address Service.” They want to compose and send mail, or retrieve and read mail. The UI and backend services are necessary parts of that outcome, but they are not the outcome itself.

For this lesson, define the journey narrowly:

Journey: An already authenticated user composes a valid email and presses Send.

The phrase “already authenticated” is deliberate. Login is a separate journey with different dependencies and user expectations. A mail application might eventually have a login SLI, address-lookup SLI, send-submission SLI, inbox-reading SLI, and message-delivery SLI. Starting with one avoids an indicator so broad that it is impossible to interpret.

A journey should be:

• Important: failure affects users or business operations meaningfully.
• Observable: the system can identify attempts and outcomes.
• Bounded: its start and successful completion are clear.
• Actionable: if the value worsens, a team can investigate a defined path.

The video below reinforces the interaction-based approach: begin with what a service interaction is, then define a successful interaction and the population being measured.

---

The five decisions that make an SLI measurable

A sentence such as “measure mail availability” is not an SLI. It leaves too much ambiguity: which operation, which requests, what does available mean, and where is the evidence?

A measurable SLI answers the following five questions.

1. What user action creates one event?

Name an atomic event that represents an attempt at the journey. For our mail service, that could be:

A POST /v1/messages/submissions request generated when an authenticated user presses Send.

The event needs a stable identifier. An idempotency key or submission ID is useful because users, browsers, and clients retry. Without one, a single slow action might be counted as several independent failures.

Be precise about when the event starts. “When the user presses Send” is closest to the user experience, but may require client-side instrumentation. “When the request reaches the API gateway” is easier to measure, but misses failures in the browser, DNS, or network path before the gateway.

Neither is universally correct. State the measurement boundary honestly.

2. Which events belong in the denominator?

The denominator is the set of eligible events: the attempts for which the service is making a reliability promise.

For the mail-submission example, a reasonable initial denominator is:

All unique send-submission requests from authenticated users that reach the mail API and pass basic request validation.

This excludes known non-user traffic such as:

• Synthetic monitoring and load-test requests.
• Internal administrative traffic.
• Malformed requests rejected because required fields are missing.
• Requests deliberately blocked as malicious or prohibited by policy.

Do not blindly exclude every HTTP 4XX response. A 400 caused by an invalid recipient format is normally outside a reliability SLI. But a widespread 401, 403, or 429 caused by an identity regression, authorization-policy error, or overload may represent a real inability for valid users to act. The definition must reflect the reason, not merely the status-code class.

3. What conditions make an event good?

A good event should represent a meaningful successful outcome, not a technically convenient response code.

For the send-mail journey, “HTTP 202 Accepted” is useful only if the API contract guarantees that the message submission has been durably recorded and queued for processing. If 202 merely means “we started trying,” it does not prove that the user’s message is safe.

A robust good-event rule could be:

A unique eligible send-submission request is good when the service sends an accepted response containing a submission ID within two seconds, after the message-submission record and outbound work item have been committed durably.

This one rule combines:

• Availability: the service gives a usable response.
• Latency: it responds within two seconds.
• Durability of the accepted submission: the service has not merely held the message in memory.

It does not prove that the message arrived in the recipient’s inbox. Delivery depends on later processing and potentially external mail systems. If delivery matters, define a separate delivery or pipeline-freshness indicator rather than quietly claiming the submission SLI measures it.

4. Where is the measurement taken?

The observation point determines what failures the SLI can and cannot see.

Measurement source	What it sees well	Important blind spot
Load balancer or API gateway logs	Requests that reached the service edge, response status, and response duration	Browser errors, DNS problems, and client-network failures before the edge
Application telemetry	Business outcomes such as “submission committed”	Requests rejected or lost before application code runs
Browser or mobile instrumentation	Closest approximation to user-perceived completion	Requires client changes; telemetry itself may be unavailable or sampled
Synthetic probe	Controlled checks across the full external path	Cannot represent all user locations, devices, accounts, or data states

For a first version, gateway and application telemetry are often the most practical combination. It captures the request at the service boundary and verifies the business event needed for the response to be truly successful. Later, browser instrumentation can improve coverage of the full user experience.

5. How will the measurement remain trustworthy?

An SLI is only useful if teams can trust its data. Define practical controls up front:

• Use a request ID or submission ID to deduplicate retries.
• Record an explicit outcome such as accepted_durable, validation_rejected, timeout, or server_error.
• Ensure the good-event counter is emitted only after the durable commit succeeds.
• Version the event schema when changing its meaning.
• Restrict access to raw logs and telemetry.
• Avoid recording message bodies, recipient addresses, authentication tokens, or other sensitive content merely to measure reliability.

This last point is a DevSecOps concern as much as an observability concern. An SLI generally needs route, timestamp, duration, outcome, and an opaque correlation ID. It rarely needs the contents of a user’s email.

---

Worked SLI: durable, timely mail submission

Here is a complete starter definition for the mail journey.

SLI specification

Name: Send-message acceptance SLI
User journey: An authenticated user sends a valid email message.
Indicator: The proportion of eligible message-submission requests for which the service confirms a durably recorded submission within two seconds.

Expressed as a ratio:

$$\text{Send acceptance SLI}=\frac{\text{eligible requests confirmed durably within 2 seconds}}{\text{eligible send requests observed at the gateway}}\times 100\%$$

Operational definition

Element	Definition
Event	A unique request to POST /v1/messages/submissions, identified by a request ID and idempotency key.
Eligible event	An authenticated, schema-valid, user-originated request reaching the mail API. Synthetic tests and internal administration requests are excluded.
Good event	The API returns its documented acceptance response, including a submission ID, in at most two seconds, and application telemetry confirms the submission and outbound task were committed durably.
Bad event	A server error, timeout, connection failure at the gateway, response slower than two seconds, or any response claiming acceptance without the required durable record.
Measurement point	API-gateway access logs joined to application telemetry using an opaque request or submission ID.
Known limitation	This implementation does not measure failures before the request reaches the gateway and does not prove delivery to the recipient.

Suppose the gateway observes 10,000 eligible submissions in a day. Of those, 9,850 satisfy the complete good-event rule. The observed SLI is:

$$\frac{9,850}{10,000}\times 100\%=98.5\%$$

That value is a measurement, not yet a promise or target. Do not immediately conclude that 98.5 percent is acceptable or unacceptable. The next stage of SLO practice is deciding what reliability level users require and what amount of failure the organization is willing to tolerate over a chosen window.

---

Avoid misleading indicators

A well-named SLI prevents its scope from being overstated. Consider these common weak definitions.

Weak metric	Why it is misleading	Better framing
“Mail service uptime”	A running process may still return errors, time out, or lose accepted work.	Measure eligible submission outcomes.
“Percentage of HTTP 2XX responses”	A 2XX response can be returned before durable work is committed.	Tie success to the documented business outcome.
“Average send latency”	Averages can conceal a painful slow tail.	Count the proportion completing within a user-relevant threshold.
“All requests are in the denominator”	Includes scanners, malformed requests, test traffic, and operations outside the promised journey.	Define eligible events explicitly.
“Messages sent successfully”	Ambiguous: accepted by the service, handed to an outbound provider, or delivered to the recipient?	Name the scope: submission acceptance, outbound handoff, or recipient delivery.

Component metrics still matter. Queue depth, authentication errors, database latency, and Pod restarts help explain why the send-acceptance SLI declines. They are diagnostic signals, not substitutes for the user-centered indicator.

A useful operational model is:

• The journey SLI tells you whether users are receiving the promised outcome.
• Component telemetry helps locate the failing boundary.
• Security telemetry helps determine whether authorization, identity, policy, or suspicious activity contributed to the problem.

---

A reusable SLI-writing template

Use this template when defining your own first SLI:

Name:
User and journey: Who is doing what?
Event: What represents one attempt?
Eligible events: What belongs in the denominator, and what is intentionally excluded?
Good event: What exact outcome, correctness condition, and time threshold make it successful?
Measurement location and source: Where is it observed, and which logs, metrics, traces, or client events provide the data?
Known gaps: Which failures or user populations does this implementation not capture?
Data handling: Which identifiers are needed, and how will sensitive data stay out of telemetry?

If you can fill in each field without vague terms such as “working normally” or “fast enough,” you have an SLI definition that can be implemented, reviewed, and improved.

---

Key takeaways

An SLI is a measurable indicator of a user-relevant service outcome, commonly represented as the ratio of good eligible events to all eligible events.

To define one well:

• Start with a bounded, critical user journey.
• Identify one observable event per attempt.
• Define the eligible population before counting success.
• Specify a meaningful good outcome, including correctness and latency where relevant.
• State the measurement point, telemetry source, limitations, and data-protection controls.
• Keep the SLI separate from its future target: an SLI measures; an SLO sets an expectation.

For the mail example, the meaningful starter indicator is not generic uptime or raw 2XX rate. It is the proportion of valid send-submission attempts that receive a durable acceptance confirmation within two seconds.

Next, you will use an SLO target and time window to calculate the error budget that follows from this kind of SLI.