Availability: definition
Availability describes whether a service successfully provides its intended function when it is expected to. Teams often express it as a percentage, but the calculation only becomes meaningful after the success condition, population and measurement window are defined.
Time-based and request-based availability
A simple time-based calculation divides available time by total measured time. A request-based service-level indicator can instead divide successful valid requests by total valid requests. These approaches can produce different results during partial failures, low-traffic periods or degraded service.
Why the definition matters
A homepage returning HTTP 200 is not necessarily “available” if checkout is broken. A regional outage may affect only part of the user population. A service can also be technically reachable but too slow to satisfy its user-facing objective. Good availability measurement therefore begins with a service outcome, not just a ping.
What to document
- The service or user journey being measured.
- The event that counts as success or failure.
- The measurement source and locations.
- The time window and treatment of maintenance.
- How partial failures, retries and timeouts are counted.
- The owner and response expected when the objective is missed.
Availability, SLOs and error budgets
An availability SLO sets a target for a defined indicator over a defined window. The gap between perfect reliability and the target can be treated as an error budget. This creates a practical connection between reliability measurements and release or risk decisions.
Common mistakes
Do not assume a single external probe represents all users, and do not compare percentages that use different windows or failure definitions. Keep the raw incident or request data so a reported percentage can be reproduced.
Related concepts
Short answer
Availability is a success ratio over a defined population and time window. The percentage is only useful when the success condition, measurement source and treatment of partial failures are explicit.
Practical checklist
- Write down what counts as a successful service outcome.
- Use the same window and population when comparing percentages.
- Define how partial failures and planned maintenance are counted.
- Keep raw incidents or request data behind every reported percentage.