What is Availability?

#How availability is calculated

The time based formula is uptime divided by total time in the measurement window. The request based formula, which is generally more meaningful for services, is successful requests divided by total requests.

The definitions differ in an important way. A service that is technically reachable but returning errors for a subset of users scores well on time based availability and poorly on request based availability, and the second number is closer to what users experience. What counts as successful also has to be defined explicitly, since a response that arrives after thirty seconds is not a success from the user's perspective.

#Why availability matters

It is the number that appears in contracts, in board reporting, and in customer conversations, which gives it weight beyond its analytical usefulness.

• Contractual basis: SLAs are usually written in availability terms with financial consequences.
• Common language: a single figure that non technical stakeholders understand.
• Investment signal: the gap between current and target availability justifies reliability work.
• Comparability: tracked consistently, it shows whether reliability is improving.

#Limits of availability as a metric

Availability treats all downtime as equivalent, which users do not. Five minutes of unavailability during peak traffic and five minutes at 4am produce identical numbers and very different consequences.

It also hides distribution. A service at 99.9% availability might have been down for forty three minutes once, or unavailable for a small group of users continuously all month. The headline number is identical and the customer experience is not remotely comparable.

#Availability vs reliability

Availability asks whether the system responds. It is a point in time property, measured over a window.

Reliability asks whether the system does what it is supposed to do correctly and consistently. A service returning fast HTTP 200 responses containing wrong data is fully available and completely unreliable. Availability is the easier property to measure, which is why it dominates reporting, but a system can hit its availability target while failing its users.

#Key takeaways

• Request based availability better reflects user experience than time based availability.
• What counts as a successful request must be defined explicitly, including a latency ceiling.
• The headline number hides distribution: one long outage and continuous partial failure can look identical.
• Availability measures whether the system responds; reliability measures whether it responds correctly.

#Frequently asked

What availability target is right?

Whatever matches user expectations and the cost of the next nine. Each additional nine costs substantially more, and most services do not need the highest tier.

Should planned maintenance count against availability?

From the user's perspective, unavailability is unavailability. Many SLAs exclude maintenance windows, which is a contractual convenience rather than a description of user experience.

How does availability relate to SLOs?

Availability is commonly the metric an SLO targets. The SLO sets the threshold and the error budget quantifies how much unavailability is acceptable.