How to Calculate Uptime Percentage: Formulas, Examples, and Common Pitfalls

Uptime percentage is the fraction of total time a system was available, expressed as a percentage. The standard formula is: Uptime % = (Total Time − Downtime) / Total Time × 100. For a 30-day month (43,200 minutes) with 22 minutes of downtime, uptime is (43,200 − 22) / 43,200 × 100 = 99.949%.

The formula is simple; the complexity is entirely in what counts as 'downtime' and what counts as 'total time'. These two definitions drive most of the gap between vendor-published uptime and the uptime your customers actually experience.

Every additional '9' in an uptime target reduces permitted downtime by an order of magnitude. Per 30-day month: 99% uptime allows 7 hours 12 minutes of downtime. 99.5% allows 3 hours 36 minutes. 99.9% (three nines) allows 43 minutes 12 seconds. 99.95% allows 21 minutes 36 seconds. 99.99% (four nines) allows 4 minutes 19 seconds. 99.999% (five nines) allows just 25.9 seconds per month.

These numbers are worth memorizing because they immediately contextualize how aggressive a given SLA really is. A '99.9% SLA' sounds strong until you notice it permits nearly 9 hours of downtime per year, enough for a single bad incident to consume the entire year's allowance.

SLAs above 99.99% are almost always marketing-grade rather than engineering-grade. Running reliably at four nines requires multi-region redundancy, automated failover, tested chaos drills, and a substantial SRE investment. Vendors who advertise five-nines without this infrastructure are usually measuring uptime against a definition that excludes most real-world failure modes.

Example 1: Simple monthly calculation. Your service was down for 18 minutes during a 30-day month. Uptime = (43,200 − 18) / 43,200 × 100 = 99.958%. This beats a 99.9% SLA easily.

Example 2: Per-component uptime. Your service publishes 20 components. One of them was in a partial outage for 4 hours during a 30-day month; the rest were available throughout, and one spent a week on degraded performance. Score each component separately: the impaired one at 100%, since degraded is not unavailable, and the outaged one at (43,200 − 240) / 43,200 = 99.444%. Then average: (19 × 100 + 99.444) / 20 = 99.972%. This is the approach PulsAPI uses. Counting components is what keeps one bad region from reading as a service-wide outage, without inventing a fraction for how much of the service an aggregate "degraded" label covers.

Example 3: Rolling-window uptime. You want uptime over a rolling 90-day window. Total time = 129,600 minutes. Total downtime across the window = 84 minutes. Uptime = (129,600 − 84) / 129,600 × 100 = 99.935%. Rolling windows smooth out month-to-month variance and are what most SRE teams actually track internally.

Vendors frequently publish uptime numbers that exceed what their customers observed. The gap comes from three main pitfalls. First, exclusion of scheduled maintenance, a window of planned downtime is often subtracted from 'total time' rather than counted as downtime, even though your customers experienced unavailability.

Second, incident-level thresholds. Many vendor SLAs define an 'incident' as requiring a minimum duration (e.g., 5+ minutes) and a minimum impact threshold (e.g., 25%+ of requests affected). A recurring 4-minute outage hitting 20% of traffic is invisible under this definition, even though customers feel it.

Third, regional scoping. A vendor with global infrastructure may publish a single global uptime number that averages across regions, hiding regional incidents that affected a large fraction of customers in a specific geography. Always ask for regional breakdowns.

The practical fix is to measure uptime yourself against the vendor's endpoints using synthetic probes. PulsAPI runs probes from multiple regions, applies weighted-interval uptime calculation, and surfaces the gap between vendor-published and real-observed uptime. For vendor contracts above $25K/year, this measurement is what you want in hand before renewal negotiations.