Uptime is the proportion of time a system is running and reachable, usually expressed as a percentage such as 99.9 percent. Availability is the broader measure of whether a service successfully serves its users, often calculated as successful requests divided by total requests. Each additional nine cuts the allowed downtime by a factor of ten.
What is uptime?
Uptime is the percentage of a period during which a service is operational. If a service was down for 43 minutes in a 30-day month, its uptime was 99.9 percent. The term is common in hosting contracts and status pages, and it is simple to communicate.
Availability is the more precise concept engineers use. A service can be "up" in the sense that its process is running and its health endpoint answers, while it fails half of all checkout requests. Availability therefore asks whether the service did its job for users, and is usually measured as a ratio:
- Time-based: good minutes divided by total minutes, where a minute counts as bad if, for example, error rate or latency exceeded a threshold.
- Request-based: successful requests divided by valid requests. This weights busy hours more than quiet ones and matches user experience more closely.
The nines: allowed downtime per availability target
The table shows the maximum downtime for common targets, based on a 365-day year, a 30-day month and a 7-day week.
| Availability | Per year | Per month (30 days) | Per week |
|---|---|---|---|
| 99% ("two nines") | 3.65 days (87.6 h) | 7.2 h | 1 h 40.8 min |
| 99.5% | 1.83 days (43.8 h) | 3.6 h | 50.4 min |
| 99.9% ("three nines") | 8.76 h | 43.2 min | 10.08 min |
| 99.95% | 4.38 h | 21.6 min | 5.04 min |
| 99.99% ("four nines") | 52.56 min | 4.32 min | 60.48 s |
| 99.999% ("five nines") | 5.26 min | 25.92 s | 6.05 s |
The formula is simple: allowed downtime = (1 − availability) × period. At four nines, a single incident that takes 15 minutes to detect and fix uses more than three months of budget. Higher targets therefore require automated detection and remediation, not just faster humans.
How dependencies compound
A request that must pass through several components in series can only be as available as their product. Three independent services at 99.9 percent each yield 0.999 × 0.999 × 0.999, about 99.70 percent end to end. A service at 99.9 percent that depends on a database at 99.95 percent reaches at most about 99.85 percent.
Redundancy works the other way. Two independent replicas at 99.9 percent, where either one can serve the request, give 1 − (0.001 × 0.001) = 99.9999 percent, as long as failures really are independent. In practice they rarely are: shared configuration, deployments, regions and DNS create correlated failures, which is why redundancy alone does not guarantee high availability.
How to measure availability
- Server-side SLIs: compute success ratios from load balancer or service metrics; precise and cheap, but blind to problems before the request reaches you.
- Synthetic monitoring: scripted checks from multiple locations detect outages even when there is no traffic, and verify DNS, TLS and CDN paths.
- Real user monitoring: shows what actual users experienced, including client-side errors.
Combine them: synthetic checks for fast detection, request-based SLIs for the SLO, and real user data to validate both. Basic liveness probes and health checks are useful for orchestration but are not a measure of availability on their own.
Uptime in SLAs and SLOs
An SLA is a contractual commitment with consequences, typically service credits, if availability falls below a threshold. An SLO is an internal target, usually stricter than the SLA, that gives the team an error budget. Read SLA definitions carefully: what counts as downtime, whether planned maintenance is excluded, how it is measured and over which period.
Best practices and common mistakes
- Pick the target from user needs and dependencies, not from ambition. A service cannot be more available than the dependencies it calls in series.
- Count partial outages. A region or a customer segment that is down is downtime for those users, even if the global average looks fine.
- Measure where users are. Monitoring from inside the same data center misses DNS, CDN and network failures.
- Do not hide behind maintenance windows. Excluding planned downtime makes reports look better but does not change what users experienced.
- Invest in recovery speed. Downtime is roughly incident frequency multiplied by time to restore, so faster detection and rollback often help more than preventing every failure.
How Obseria helps
Obseria measures availability from server-side metrics, synthetic checks from 50+ locations and real user monitoring, and turns them into SLOs with error budgets and burn-rate alerts. Public or internal status pages communicate incidents, and the Obseria platform itself is offered with a 99.95 percent SLA. To shorten the downtime that remains, see how teams reduce MTTR.
