Definition
Availability is the percentage of time a system is operational and accessible to users within a given time period. It is one of the most fundamental metrics in reliability engineering and is the basis for most Service Level Agreements (SLAs) and Service Level Objectives (SLOs).
Availability (%) = (Uptime ÷ Total time) × 100
Equivalently: Availability (%) = (Total time − Downtime) ÷ Total time × 100
How availability is measured
Availability is typically measured over a rolling time window — most commonly 30 days or 1 year. The measurement method matters: some teams measure availability as uptime of the service process (is the server running?), while others measure it as successful request rate (are requests completing without error?). The latter is generally more meaningful to users.
Modern SRE practice measures availability through Service Level Indicators (SLIs) — specific, quantitative measurements of service behavior. A common SLI for availability is: percentage of HTTP requests returning a non-5xx response code over a rolling 30-day window.
The "nines" — availability tiers
Availability targets are described by the number of 9s in the percentage. Each additional nine reduces allowed downtime by roughly 90%.
| Availability | Nines | Downtime per year | Downtime per month |
|---|---|---|---|
| 99% | Two nines | 87h 36m | 7h 18m |
| 99.9% | Three nines | 8h 45m | 43m 49s |
| 99.99% | Four nines | 52m 35s | 4m 22s |
| 99.999% | Five nines | 5m 15s | 26.3s |
| 99.9999% | Six nines | 31.5s | 2.6s |
See the Five Nines Availability Table for the complete reference including per-week, per-day, and per-hour breakdowns.
Availability vs reliability
Availability and reliability are related but distinct concepts. Availability answers "is the system up right now?" Reliability answers "does the system perform consistently over time?"
A system can be highly available but unreliable: it responds to all requests (100% availability) but returns incorrect results 10% of the time. Conversely, a system can be reliable but unavailable: it always works correctly when running, but crashes frequently.
Modern SLOs typically capture both dimensions — measuring availability (requests that complete) and correctness (requests that complete successfully with the right result).
Availability vs uptime
Uptime and availability are often used interchangeably but have a subtle difference. Uptime refers to whether a system process is running. Availability refers to whether the system is usable by end users. A service can have 100% uptime (the process never crashes) but poor availability if it is overloaded and returning errors on every request.
For user-facing systems, availability measured at the request level is more meaningful than process uptime.
Planned vs unplanned downtime
Most SLAs distinguish between planned maintenance windows and unplanned outages. Planned downtime — scheduled deployments, database migrations, infrastructure upgrades — is typically excluded from SLA calculations if customers are given adequate advance notice.
At higher availability tiers (four nines and above), planned maintenance windows become impractical. With only 52 minutes of annual downtime budget at 99.99%, a single 1-hour maintenance window would breach the SLA. Teams at this level require zero-downtime deployment practices.
Composite availability
When a system depends on multiple components in series, the combined availability is the product of each component's individual availability. If your API gateway has 99.9% availability, your database has 99.95%, and your cache has 99.99%, the end-to-end availability is approximately 99.84% — lower than any individual component.
Use the Composite Availability Calculator to calculate the combined availability of your specific system.
How to improve availability
The primary levers for improving availability are: reducing the frequency of failures (better testing, smaller deployments, chaos engineering), reducing the duration of failures (better alerting, runbooks, automated rollback), and adding redundancy (multiple instances, geographic replication, active-active architectures).
The most cost-effective first step is usually improving MTTR — reducing how long outages last — rather than trying to prevent all failures. See the MTTR Calculator and What is Observability? for more on this approach.