Uptime
Also called availability.
The share of time a service is working and reachable, usually written as a percentage such as 99.9%.
Last updated
What it is.
Uptime is measured over a period, often a month. Each extra nine cuts the allowed downtime by ten. Over a 30-day month, 99% allows about 7.2 hours down, 99.9% about 43 minutes, and 99.99% about 4.3 minutes.
How it is measured matters as much as the number. A service can respond to a health check and still fail for users. Better measures count successful user requests, which is what an SLO does.
Why it matters
Uptime is what users feel. It is also what an SLA promises, so it drives how much to spend on redundancy, monitoring and on-call. Each extra nine costs more than the last, so the right target depends on what downtime costs the business.
In a product build
OceanLab publishes 99.9% uptime on its homepage. Reaching a target like that in a product build comes from the hosting set-up, monitoring, rollback and recovery plans decided before launch.
Common mistakes.
- 01
Promising four nines on infrastructure that has a single database.
- 02
Not counting planned maintenance, which users experience as downtime anyway.
- 03
Forgetting dependencies: your uptime cannot beat the services you rely on without fallbacks.
Related terms.
- SLA (service level agreement)A contract that promises a level of service, such as uptime or support response time, and says what happens if it is missed.
- SLO (service level objective)An internal reliability target for a service, such as 99.9% of requests succeeding, measured by a service level indicator (SLI).
- RTO (recovery time objective)How long a system can stay down after a failure before the outage seriously harms the business.
- RPO (recovery point objective)The point in time to which data must be recoverable after an outage: in practice, how much recent data you can afford to lose.
Guides and pages
Browse the full glossary or read answers to common questions.
