When Slow Counts as Down: Setting a Service Level Objective for Latency

The dashboard shows 100% availability. The health check responds as expected. No alert fired all morning. And yet every payment request takes several seconds, some users abandon halfway through, and the support team starts receiving complaints before the technical team realises there is a problem.

For the people using the service, this is a failure. For monitoring designed around "up or down", nothing happened.

What practice says in 2026

The report is based on 418 responses from practitioners across sectors, company sizes and geographies. The figure measures perceived severity, not measured impact, but perception is already enough to change a decision: if two thirds of the people running systems put slowness on the same level as an outage, reliability management that only measures outages is leaving half of the problem out.

SLI and SLO, in plain terms

Site reliability engineering (SRE) organises this topic around two concepts.

A service level indicator (SLI) is a carefully defined quantitative measure of some aspect of the service provided. Request latency, the proportion of requests that fail and availability are all indicators.

A service level objective (SLO) is the target value, or range of values, for that indicator. "95% of payment requests respond in under 800 milliseconds, measured over 30 days" is an objective. The specific number is an example, not a recommendation: the right threshold depends on the journey and on who uses it.

The chapter on service level objectives in Google's SRE book lists request latency as one of the indicators most services consider. In practice, many operations have an availability objective and none for latency. That is where degradation goes unnoticed.

Why the average misleads

The temptation is to measure average latency. The problem is that the average hides exactly what matters.

A service can have a comfortable average while one request in twenty takes ten times longer. Those slow requests are not always random: they can cluster at peak hours, among users with the most data or in the heaviest operations, which are often the most valuable ones.

Percentiles solve this. Measuring the 95th or 99th percentile shows the shape of the distribution and exposes the slow tail, where the dissatisfied user is. The same chapter of Google's SRE book argues for exactly this choice: percentiles show what the average erases.

One objective per critical journey, rather than one global objective for the whole service, is the next step. Checking a balance and submitting a payment do not have the same tolerance for waiting.

Measuring from where users are

One measurement detail changes the result. Latency measured at the server does not include the network, the region or the path the request travels to get there. A service can respond quickly inside the data centre and still arrive slowly for the person on the other side.

The Catchpoint report stresses this point: without monitoring from where users actually are, the view of reliability is incomplete. For a latency objective, that means choosing the measurement point with the same care as the threshold.

When latency burns the error budget

A service level objective creates, by definition, an error budget: the margin of failure the objective accepts. If the target is 95% of requests below the threshold, the remaining 5% is the budget.

The decision that separates a mature operation from one that is merely monitored is this: when latency consumes the error budget, the case is handled as an outage. Same alert path, same owner, same post-incident review.

What is still missing is the link to the business. In the same report, only 26% of practitioners directly assess whether performance improvements affect business metrics such as revenue or customer satisfaction. A latency objective without that link protects the service but cannot defend the investment it requires. It is the same logic already visible in DORA metrics on delivery stability: what is not measured in business terms ends up losing the budget discussion.

Five questions before calling a service reliable

• Are the critical journeys of the service identified and named?
• Does each critical journey have a latency indicator defined, in addition to availability?
• Is the objective expressed as a percentile rather than an average?
• Is latency measured from where users are, or only from the server?
• Is there a named owner who acts when latency consumes the error budget?

Conclusion

Reliability is not only staying up. It is staying fast enough to be used. Until latency has an objective of its own, with a percentile, a measurement point and an owner, degradation remains the failure the operation does not see and the user always does.

To define these objectives for critical journeys, with senior capacity that reinforces the in-house team, as described in the comparison between SRE as a service and an in-house team, it is possible to book a Clarity Session, with no commitment.