Uptime Percentages Explained: The Nines and Allowed Downtime

An uptime percentage is the share of a time period during which a service was available. A target such as 99.9% is a promise, or a goal, about how much downtime is acceptable. Because the numbers all look close to 100%, it helps to convert them into actual minutes and seconds.

The formula

Allowed downtime is the unavailable fraction multiplied by the period length:

allowed downtime = (1 - uptime%) x period length

99.9% over 30 days:
(1 - 0.999) x 30 days x 24 h x 60 min = 0.001 x 43,200 min = 43.2 min
                                       = 43 minutes 12 seconds

The reverse is just as simple: uptime% = (period length - downtime) / period length x 100.

Conventions used in this guide

Different sources quote slightly different figures because they use different period lengths. All numbers below use these conventions:

• Day = 24 hours = 86,400 seconds.
• Week = 7 days = 604,800 seconds.
• Month = 30 days = 2,592,000 seconds. A 31-day month allows about 3.3% more downtime; February allows less.
• Year = 365 days = 31,536,000 seconds. Some sources use 365.25 days, which adds roughly 0.07%.

The nines table

To calculate any other target or period, including custom months, use the uptime calculator.

What each level means in practice

• 99% allows more than 7 hours of downtime a month. Users will notice. It is a floor for hobby projects rather than a business target.
• 99.5% allows about 3.5 hours a month, roughly one bad afternoon. Common for internal tools.
• 99.9% is the most common target for SaaS products and business websites. 43 minutes a month leaves room for one moderate incident.
• 99.95% leaves about 22 minutes a month. It usually requires redundancy and deployments that do not cause downtime.
• 99.99% leaves about 4 minutes a month. A single slow manual response consumes the whole budget, so this level typically requires automatic failover.
• 99.999% leaves under 30 seconds a month. It is associated with telecom and critical infrastructure and is rarely realistic for a typical web application.

Why each extra nine is so expensive

Every additional nine divides the allowed downtime by ten, but the engineering cost rises much faster. Going from 99.9% to 99.99% means detecting, diagnosing and fixing problems in minutes instead of within an hour. That requires redundant infrastructure across failure domains, automated failover, careful change management and fast alerting. A useful sanity check: your target cannot exceed the availability of the things you depend on, such as your hosting provider, DNS, payment processor and database, unless you have redundancy for each.

Measurement affects the number

The same outage can produce different uptime figures depending on how it is measured:

• Check interval. A monitor that checks every 5 minutes cannot see a 2-minute outage that falls between checks. Shorter intervals give a more accurate record.
• Time-weighted vs check-count. Counting the share of successful checks is simpler, but time-weighted availability, where an outage counts from the first failed check to the first successful one, reflects real duration better.
• Maintenance windows. Many SLAs exclude scheduled maintenance. Decide up front whether yours does.
• Partial outages. A site that loads but whose checkout fails may count as "up" if you only monitor the homepage.
• Request-based measurement. Some teams measure availability as successful requests divided by total requests instead of time. This is common for SLOs; see SLA, SLO and SLI explained.

Uptime Tracker reports time-weighted availability per monitor, with outages backdated to the first failed check, and excludes maintenance windows from availability.

Dependencies multiply: composite availability

When a request must pass through several components in sequence, their availabilities multiply. If your application depends on a web server, a database and a payment API, each at 99.9%, and any one failing breaks checkout, the best you can expect for checkout is 0.999 x 0.999 x 0.999 = 99.70%. That is about 2 hours 10 minutes of potential downtime in a 30-day month, three times the budget of any single component.

Redundancy works the other way. Two independent replicas, each at 99%, where either one can serve traffic, are both down only 1% x 1% = 0.01% of the time, giving 99.99% in theory. In practice failures are rarely fully independent, because replicas often share a network, region, configuration or deployment, so real gains are smaller.

How to choose an uptime target

1. Start from user impact. How much does an hour of downtime cost in revenue, support load and trust? The downtime cost guide has a formula.
2. Measure your current baseline for at least a month before committing to a number.
3. Check your dependencies. Your target should be no higher than what your providers support.
4. Set an internal goal stricter than any external promise. If you promise customers 99.9%, aim internally for 99.95% so you have margin.
5. Review quarterly. Tighten the target only when you consistently beat it and users would notice the difference.

Uptime for a single month: a worked example

Suppose your site had three incidents in a 30-day month lasting 12, 9 and 25 minutes. Total downtime is 46 minutes. Availability is (43,200 - 46) / 43,200 = 99.894%. That narrowly misses a 99.9% target, which allowed 43.2 minutes. Over a 31-day month (44,640 minutes), the same 46 minutes would be 99.897%, still just under.