Measure whether people can finish the task

Start with one important journey

Consider a portal where a customer submits a service request and receives a reference number. The API can return a fast accepted response while a downstream job fails to create the request. Server availability looks healthy, but the customer has no usable record.

Define the outcome in ordinary language before choosing a query. For this workflow, a valid submission should become a retrievable request within the agreed time. That statement identifies both correctness and delay.

Choose a small set of important journeys rather than measuring every endpoint equally. A frequently requested decorative asset should not dominate the reliability story of a rarely used but essential submission path.

Define good and eligible events

A ratio needs a clear numerator and denominator. State which attempts count, what makes an attempt good and how retries are handled.

For an asynchronous request, counting only completed jobs omits work that never finishes. Track accepted operations and determine whether each reaches the required result by its deadline.

Choose where to observe

Server measurements are useful but miss some requests that never reach the application. Browser telemetry and synthetic checks can reveal different parts of the journey, each with their own coverage and failure modes.

Explain what the chosen implementation can see. A synthetic test using one network path does not represent every customer. Browser telemetry can be absent when the page fails before it starts.

Use complementary evidence where the consequence justifies it. Do not merge incompatible populations into one precise-looking percentage without describing what it means.

Keep the target separate from the measurement

The indicator reports observed service. The objective states the level the team intends to provide over a defined window. Agree the target according to user needs and achievable operation, rather than copying a familiar number.

Google's SRE guidance describes indicators and objectives as tools for reliability decisions. Their practical value comes from using the result to choose work and respond to degradation, not merely displaying another dashboard.

Make the result actionable

Assign an owner, a review process and a response when the service falls outside the objective. Keep diagnostic metrics nearby so the team can investigate without turning the user-facing measure into a list of infrastructure symptoms.

Revisit the definition when the workflow changes. An indicator that still measures an old synchronous endpoint can become misleading after work moves to a queue. The measure should follow the task the user now depends on.