To calculate uptime percentage, divide the time a service was up by the total time in the window, then multiply by 100. The formula is uptime % = (total time minus downtime) / total time times 100. For a 30-day month of 43,200 minutes with 22 minutes of downtime, that is (43,200 minus 22) / 43,200 times 100 = 99.95%. The three things that trip people up are choosing the window, deciding what counts as down, and remembering that your check interval limits how precise the number can be.
The arithmetic is easy. The judgment around it is where uptime numbers become either trustworthy or meaningless. Below is the formula, worked examples across the common targets, and the traps that make two people measuring the same service report different numbers.
The formula
Uptime percentage is availability expressed as a share of a time window:
uptime % = (total time − downtime) ÷ total time × 100
Both values have to be in the same unit, usually minutes or seconds. "Total time" is every minute in the window, including nights and weekends, unless your agreement says otherwise. "Downtime" is the sum of every confirmed outage in that window. Everything hard about the calculation is hidden in those two definitions, not in the division.
Worked examples
Using a 30-day month of 43,200 minutes, here is how a given amount of downtime maps to the availability percentage, and to the named SLA tiers.
| Downtime in the month | Calculation | Uptime % |
|---|---|---|
| 7h 18m (438 min) | (43,200 − 438) / 43,200 | 99.0% |
| 43m 50s | (43,200 − 43.8) / 43,200 | 99.9% |
| 21m 54s | (43,200 − 21.9) / 43,200 | 99.95% |
| 4m 23s | (43,200 − 4.38) / 43,200 | 99.99% |
| 26s | (43,200 − 0.43) / 43,200 | 99.999% |
To run the reverse calculation, from a target percentage to the downtime it allows, enter any value here:
alertping ▸ downtime calculator
- allowed downtime per year
- 52m 36s
- per quarter
- 13m 9s
- per month
- 4m 23s
- per week
- 1m 1s
- per day
- 8.6s
A 5-minute check interval can miss a whole month of budget at four nines. AlertPing checks every 30 seconds, so the number above is one you can actually measure.
Notice how little downtime separates the top tiers. The gap between 99.9% and 99.99% is 39 minutes a month, but the gap between 99.99% and 99.999% is under 4 minutes. This is why each additional nine is so much harder to hold, a point we go deeper on in what is five nines uptime. For the tier most SLAs actually quote, see what 99.9% uptime means in hours and minutes.
Trap one is which window you measure
The same outage produces a different percentage depending on the window. Ten minutes of downtime is 99.98% of a month but only 99.31% of a single day. Report uptime over too short a window and one bad afternoon wrecks the number; report over a year and a serious outage disappears into the average. Most SLAs measure per calendar month and reset on the first, which is a reasonable default. Whatever you choose, state it, because a percentage without a window is not a fact.
Trap two is what counts as down
Downtime is not only "the server returned an error." A page that responds with a 200 status but renders an error, an API that answers but returns the wrong payload, or a response so slow the user gives up: all of those are down from the customer's point of view, even though a naive check calls them up. If your monitoring only reads the status code, your uptime number will be flatteringly high and quietly wrong. Assert on the response body and the response time, the same way you would in API monitoring, so the number reflects what users actually got.
Maintenance is the other half of this. Most agreements exclude scheduled, pre-announced maintenance from the downtime total, which is fair. Hiding an unplanned outage under a maintenance label to protect the percentage is not. If you are reporting uptime against a commitment you signed into a contract, the honesty of that exclusion is the whole ballgame.
alertping
Let the monitor do the arithmetic
AlertPing totals your confirmed downtime and publishes the rolling uptime percentage for you, measured from 30-second checks across two regions, so the number is calculated, not estimated.
Trap three is that your check interval caps the precision
You can only measure downtime in units of your check interval. If you check every five minutes, every outage you record is a multiple of five minutes, and any outage shorter than that can slip between two checks unseen. So a five-minute monitor cannot credibly report 99.99%, because the entire monthly budget for that tier is 4 minutes and 23 seconds, less than one check gap.
The rule is simple: your check interval must be shorter than the downtime your target allows, ideally much shorter. For any target at or above 99.9%, a 30-second interval gives you both early detection and the resolution to state outage length to the second rather than the nearest five minutes. The full breakdown of interval versus target lives on the SLA monitoring page.
Putting it together
Calculating uptime percentage is one division. Reporting a number you can defend is three decisions: pick a window and name it, define what counts as down and measure exactly that, and use a check interval short enough that the precision is real. Get those right and the formula gives you a figure a customer's procurement team can trust. Get them wrong and you have a number that looks good until the first dispute, which is the worst time to discover your measurement was optimistic.