Service level indicators
Define the denominator before agreeing on reliability
A percentage can change dramatically when failed attempts are excluded. Agree what counts as an eligible operation and keep that definition stable enough to compare results.
In this article
Work through a small example
Suppose a synthetic service receives 1,000 valid submissions. Ten fail before a job is created, and another ten never finish. Counting only the 990 created jobs or only the 980 completed jobs tells a different story from counting the original valid attempts.
Choose the population that matches the user's expectation and the measurement's observation point. If the system cannot observe failures before admission, state that limitation rather than presenting the result as complete end-to-end coverage.
The denominator is part of the service definition, not a convenient query filter.
Classify expected rejection carefully
Invalid input and denied access may be correct application behaviour. Decide how they are treated in the indicator and keep them visible in appropriate diagnostic or product measures.
Do not exclude all client errors automatically. A release that generates invalid requests from its own interface can harm users while every response is technically a client-error status.
Use workflow context to distinguish user mistakes from a broken application path.
Preserve comparability
Version the indicator definition when eligibility or success rules change. Annotate dashboards and avoid comparing percentages across incompatible definitions without explanation.
Keep numerator and denominator counts available beside the ratio. This helps identify low traffic, missing instrumentation and sudden population changes.
For segmented views, ensure categories are meaningful and bounded. Avoid averaging percentages from groups with very different event counts as though each group carried equal traffic.
Review with the service owner
Walk through successful, failed, retried, cancelled and timed-out examples with the people responsible for the user journey. Calculate their expected contribution manually.
Then validate the implementation against those examples. A correct SQL expression is not enough if the agreed population was misunderstood.
Accept the measure when its scope, exclusions and limitations are understandable. That gives the team a reliable basis for setting an objective and making changes, instead of negotiating over a percentage whose meaning shifts with each incident.
Primary sources
Google SRE: implementing service objectivesReferences checked 11 September 2026.