Availability SLI

An availability SLI measures the proportion of eligible requests or time that meets a defined success condition. Its meaning depends on the measurement window and on clear rules for success and eligibility.

An availability service level indicator (SLI) quantifies how often a service is usable according to a defined success criterion. It is commonly calculated over a time window as successful eligible requests divided by all eligible requests. The result is often expressed as a percentage.

For a request-based SLI, teams decide which requests count and what counts as success. For example, they might count a request as successful when it returns a valid response without a server error. The exact rule should reflect what users consider usable, rather than relying on a status-code convention without thought.

Some systems measure availability by time instead: the fraction of the window during which the service meets an availability condition. This can suit services where request counts are unavailable or where each period of downtime matters regardless of traffic. Request-based and time-based measurements can produce different results, especially when traffic varies.

An SLI is a measurement, not a guarantee or target. A service level objective (SLO) sets a desired value for an SLI over a specified window, such as 99.9% successful requests over 30 days. Clear eligibility rules, consistent instrumentation, and an explicit window make the measurement useful for decisions.

Key points

• Define which requests or periods are eligible for measurement.
• For request-based availability, divide successful eligible requests by all eligible requests.
• Specify the success criterion, measurement window, and treatment of retries or non-user traffic.
• Availability measurement and the SLO target are different things.

Interview questions

What is an availability SLI, and how would you calculate one?

An availability SLI is a measurement of how often a service meets a defined usability criterion. For a request-based measure, I would divide successful eligible requests by all eligible requests in the measurement window. I would state what counts as success and which requests are included. The result can then be compared with an SLO.

How would you design a request-based availability SLI for an API?

I would first identify the user-facing operation and define which requests belong in the measurement. Then I would select a success condition, such as receiving a usable response, and calculate successful requests divided by all eligible requests over a stated window. I would verify that instrumentation captures failures consistently, including timeouts and relevant dependency failures. Finally, I would compare the measured value with the corresponding SLO, if one exists.

How do you choose between request-based and time-based availability?

I would choose a request-based or time-based definition based on what best represents user impact and what the system can measure reliably. Request-based measurement weights periods by traffic, so a failure during a busy period can contribute more than an equally long quiet-period failure. Time-based measurement instead weights intervals, and therefore needs a clear rule for deciding when the service is available. I would document the semantics, validate the telemetry against incidents, and avoid combining unlike populations into one number.

What can make a request-based availability number misleading?

A request-based availability ratio needs a sensible denominator: requests that users actually attempted and that the service is responsible for handling. If failed requests are omitted, availability will be overstated; if unrelated checks are included, the result may not represent user experience. Retries also need deliberate treatment because counting each attempt can differ from measuring whether the user's overall operation succeeded. I would document these rules and keep them consistent over time.