Failure from the user’s perspective
The server responds, but an application cannot be saved. Technical monitoring shows availability while the user experiences a failure. Service reliability is measured through the actions the service exists to support: finding a record, submitting a request or obtaining a document.
Imagine enrolling in a class
Imagine a fictional city service. Class pages open quickly, but saving a selected place sometimes fails. Homepage checks show availability while parents must restart registration. Different observers accurately describe different parts of one process.
One measure could be the share of valid registration attempts that actually reserve a place and show confirmation. Define how repeated clicks and unfinished actions count. Otherwise interface improvements may change attempt counts and move the metric without changing operation reliability.
A percentage needs a denominator
A measure needs an observation period, included operations and success criteria. User input mistakes and system failures differ, but disputed cases must not be excluded retrospectively to improve results. Record counting rules before discussing the final number and revise them explicitly.
In an illustrative example, ten failed attempts out of a thousand equal one percent. This is example arithmetic, not a real service assessment. Ten different people and ten retries by one person create different experiences. Where useful, show affected-user counts alongside operation percentages.
Speed and correctness complement availability
An operation may succeed so slowly that people abandon it. Success definitions may therefore include acceptable waiting time. Averages can hide occasional long delays; inspect distributions and slow cases separately. The measurement method should fit the service's purpose.
Meaning can be wrong too: a booking is saved for the wrong date. A technical success response will miss that problem. Reference-journey tests and user reports complement infrastructure observations. As Google SRE notes, server-only measurements can miss problems visible to clients.
Targets should change team decisions
Repeated SLO breaches need an agreed response: investigating causes, reducing the risk of the next change or allocating time to a recurring fault. Without a connection to work, the target is decorative. Owners should know which actions deterioration triggers and who decides.
Do not habitually give every function the same target. Reading a reference page and submitting an important request have different failure consequences. Stricter expectations require development, testing and support resources. Discuss user impact and recovery cost rather than the prestige of a large percentage.
Begin with one transparent measure
Choose a critical journey, define success and verify the numerator and denominator sources. Compare observations with known failures: did the measure reflect them? If people could not work while the number stayed perfect, refine the measurement.
