Uptime percentage is the time a service was up divided by the total time, multiplied by 100. A 30-day month has 43,200 minutes; with 27 minutes of downtime, uptime is (43,200 − 27) ÷ 43,200 × 100 = 99.9375%.
The formula is simple. Getting a number you can defend is harder: you have to decide what the total time is, what counts as downtime, what to leave out and how to combine several parts of a system. This guide works through each with examples, then explains how uptime differs from availability and reliability.
For a quick answer, the uptime calculator turns downtime into a percentage and a percentage into allowed downtime.
The uptime formula
Uptime % = (Total time − Downtime) ÷ Total time × 100Total time and downtime must be in the same unit. Minutes are the practical choice for a month, seconds if you need more precision.
| Period | Minutes | Seconds |
|---|---|---|
| Day | 1,440 | 86,400 |
| Week | 10,080 | 604,800 |
| 30-day month | 43,200 | 2,592,000 |
| 31-day month | 44,640 | 2,678,400 |
| Average month (30.4375 days) | 43,830 | 2,629,800 |
| Year (365.25 days) | 525,960 | 31,557,600 |
Use the real length of the period when you report on a contract, since most SLAs are measured per calendar month. The calculator uses the average month so that targets compare fairly, which is why it shows 99.938% for the same 27 minutes.
From checks instead of minutes
If your data is a list of checks rather than outage times, uptime is the share of checks that succeeded:
Uptime % = Successful checks ÷ All checks × 100With a check every minute, a 30-day month has 43,200 checks. If 40 of them failed, uptime is 43,160 ÷ 43,200 × 100 = 99.907%. This only works when checks run at a fixed interval, and it treats every failed check as a whole interval of downtime. With checks every five minutes, a 30-second outage either counts as five minutes or not at all.
Worked examples
Several incidents in one month
A shop had three incidents in a 30-day month: 12 minutes on the 4th, 7 minutes on the 15th and 24 minutes on the 27th. Add them up first: 43 minutes. Then (43,200 − 43) ÷ 43,200 × 100 = 99.9005%. A 30-day month at 99.9% allows 43 minutes 12 seconds, so the shop stayed within the target with 12 seconds to spare.
Excluding scheduled maintenance
If your SLA excludes maintenance, take the maintenance time out of the total, not just out of the downtime:
Uptime % = (Total time − Maintenance − Downtime) ÷ (Total time − Maintenance) × 100An example: a 30-day month with a 2-hour maintenance window and 30 minutes of unplanned downtime. Excluding maintenance: (43,200 − 120 − 30) ÷ (43,200 − 120) × 100 = 99.930%. Counting the maintenance as downtime instead: (43,200 − 150) ÷ 43,200 × 100 = 99.653%. The same month, two very different numbers, which is why the SLA has to say which one applies.
Paused monitoring works the same way. If nobody was measuring, that time is neither up nor down, and it belongs out of the total.
Combining the uptime of several components
Most services depend on more than one thing. How you combine their uptime depends on whether they are chained or redundant.
Components in a chain
When every component must work, multiply their uptimes. A site that needs both an app server at 99.9% and a database at 99.9% can at best reach 0.999 × 0.999 = 99.8%, assuming they fail at different times. Add a payment provider at 99.9% and checkout drops to about 99.7%. Each dependency you add lowers the ceiling.
Redundant components
When either of two components can do the job, the service is down only when both are. Two servers at 99% each give 1 − (0.01 × 0.01) = 99.99% in theory. In practice they often share a network, a deploy or a configuration mistake, so they fail together more often than the math assumes. Treat the result as an upper limit, not a promise.
Don’t average across monitors
If the homepage had 100% and checkout 99.0%, an average of 99.5% describes nothing that customers experienced. Report each component on its own, and define in advance which ones make up “the service” in your SLA.
Uptime vs availability vs reliability
The three words are often used as synonyms. They measure different things, and knowing which one you mean makes the number more useful.
- Uptime is the share of time the service was reachable and answering. It is what the formula above calculates, and what most SLAs mean.
- Availability is the share of time the service was usable: reachable, correct and fast enough. A page that loads in 40 seconds is up but not available. If you count slow or wrong responses as failures, you are measuring availability.
- Reliability is how long the service runs without failing, usually measured as MTBF (mean time between failures). It says how often things break, not how long they stay broken.
Availability connects the two other numbers through a classic formula:
Availability = MTBF ÷ (MTBF + MTTR)MTTR is the mean time to recovery. A service that fails on average every 720 hours (once a month) and takes an hour to recover has 720 ÷ 721 = 99.86% availability. The formula also shows the two ways to improve it: fail less often, or recover faster. MTTR, MTTA and MTBF explained covers how to measure and improve each.
Two services with the same uptime can feel very different. One 43-minute outage a month and 43 one-minute outages a month give the same percentage, but the second breaks your users’ work every day. That is why it is worth tracking the number of incidents next to the uptime percentage.
Common mistakes
- Measuring from inside. Server logs can’t record a request that never arrived. DNS problems, expired certificates and network failures only show up in external checks.
- Counting every blip. A single failed check is often the network, not your service. Confirm failures with a second check before counting them as downtime, or your numbers will be lower than what users experienced.
- Rounding up. 99.896% is not 99.9%. When you compare against a target, round down, or show enough decimals to tell them apart.
- Checking too rarely. The check interval sets the resolution. Checking every 5 or 10 minutes can’t tell you whether you met a 99.95% month, which allows 22 minutes.
- Checking only the homepage. A cached homepage can stay up while login or checkout fail. Monitor the paths users depend on.
Getting the numbers without a spreadsheet
Uptimecheck works out uptime the way this guide describes. Uptime monitoring checks every minute from Stockholm, Sweden, and confirms each failed check with a second one about 10 seconds later. Uptime is the share of the period without a confirmed outage; maintenance windows and paused time don’t count against it.
- Reports show uptime, downtime and incidents per monitor for this month, last month or the last 7, 30 or 90 days, against an SLA target from 99% to 99.99%, with a CSV download. See how to run reports against an SLA target.
- Client reports send the same numbers to the people you work for. See client reports.
- Status pages show customers 90 days of uptime history per component. See status pages.
To see what a target allows before you commit to it, read what 99.9% uptime means or try the SLA and uptime calculator.
Stop calculating uptime by hand. Try Uptimecheck free for 14 days, no credit card required.