Availability Calculation

Availability is a ratio whose meaning depends on what counts as an eligible event and a success. For request-based SLI calculations, divide successful eligible requests by all eligible requests in the same window, then compare the result with an SLO if one is defined.

Availability is an indicator of whether a service is usable, but its exact meaning depends on the measurement rule. In an SLI, define which events count as eligible and which outcomes qualify as successful. For example, a request may count as successful only if it returns an accepted status within a latency threshold.

For a request-based calculation, divide the number of qualifying successful requests by the number of eligible requests in the measurement window. Multiply by 100 for a percentage. Exclusions such as health checks or invalid client requests should be explicit and applied consistently.

A time-based calculation instead divides qualifying time by total measured time. It might count minutes when a health check passes, but that result can hide the impact on users if a partial outage affects only some requests. Request-based and time-based availability therefore answer different questions.

An SLI is the measured indicator; an SLO is the target for that indicator over a stated window. When presenting availability, name the measurement method, eligibility rules, success criteria, and window so the number can be interpreted and reproduced.

Key points

• Define eligible requests and successful outcomes before computing the ratio.
• Request-based availability is successful eligible requests divided by all eligible requests.
• State the measurement window and exclusions to make the result reproducible.
• A time-based metric weights time intervals rather than individual requests.
• An SLI is a measurement; an SLO is a target applied to it.

Interview questions

How does request-based availability differ from time-based availability?

Request-based availability weights each request equally, so busy periods contribute more observations than quiet ones. Time-based availability weights intervals, such as minutes, equally regardless of request count. If an outage occurs during a low-traffic period, the request-based metric may look better than the time-based metric. The choice should reflect the user impact the SLI is intended to represent.

What is the difference between an SLI and an SLO?

An SLI is the actual measurement, such as the fraction of requests completed successfully within a latency bound. An SLO is the goal for that measurement over a specified period, such as a target percentage over a rolling month. The SLO needs the SLI definition to be meaningful and auditable. A service can meet or miss the SLO based on observed SLI data.

How would you calculate request-based availability for an API?

For request-based availability, I count eligible requests that meet the success definition and divide by all eligible requests in the same window. I would state whether success includes latency limits as well as response status. I would also document exclusions, such as probes or malformed client traffic, rather than silently dropping events. The SLI value can then be compared with an SLO target for that window.

An availability SLI suddenly improves while users report failures. How would you investigate?

First I would verify the event population, outcome classification, and aggregation window, then check that numerator and denominator use the same eligibility rules. I would examine whether traffic shifts or partial failures distort the metric, and compare request-based results with relevant latency or time-based indicators. I would also validate telemetry for missing, duplicated, or delayed events. Only after validating the measurement would I treat a threshold breach as a service reliability regression.