Uptime and downtime calculator
An availability target is a downtime budget written as a percentage. This converts it back.
Enter an availability target and the calculator returns the downtime it permits over a year, a month and a week — then divides that budget by your mean time to repair to show how many separate incidents it actually survives.
That second number is the useful one. Four nines sounds like a property of the equipment; it is really permission for about 52 minutes of outage a year, which at a four-hour repair time is not even one incident.
Worked example — four nines at a four-hour repair time
The standard colocation commitment, converted into the operational reality behind it.
- Availability target — 99.99% — four nines. The percentage of the period the service is required to be available.
- Mean time to repair — 4 hours. Detection, dispatch, diagnosis and restoration — the full wall-clock time a user is affected, not the time spent holding a tool.
- Excluded maintenance — 0 hours/year. Planned windows the agreement excludes from the availability calculation.
Downtime allowed per year: 52 m 33 s — 99.9900% availability measured over 8,760 hours
| Per month | 4 m 22 s |
|---|---|
| Per week | 1 m 0 s |
| Per day | 8 s |
| Unavailability | 0.0100% |
| Incidents the budget survives Less than one — the target depends on the fault not reaching the user | 0.22 at 4.0 h MTTR |
| MTTR needed for 4 incidents a year | 13 m 8 s |
At 4.0 h to repair, a single incident already exceeds the annual budget. A target like this is a statement about redundancy and failover, not about how quickly anyone can fix something.
Formula
Downtime = period × (1 − availability ÷ 100)
Then: incidents survivable = annual downtime budget ÷ mean time to repair. Excluded maintenance shortens the measured period, which raises the absolute downtime a target permits.
Availability targets and what they permit
Measured over a full 8,760-hour year with no excluded maintenance. Generated by the same function as the calculator above, so the two cannot disagree.
| Availability | Per year | Per month | Per week |
|---|---|---|---|
| 99% | 3 d 15 h | 7 h 18 m | 1 h 40 m |
| 99.5% | 1 d 19 h | 3 h 39 m | 50 m 21 s |
| 99.9% | 8 h 45 m | 43 m 48 s | 10 m 4 s |
| 99.95% | 4 h 22 m | 21 m 54 s | 5 m 2 s |
| 99.99% | 52 m 33 s | 4 m 22 s | 1 m 0 s |
| 99.999% | 5 m 15 s | 26 s | 6 s |
| 99.9999% | 31 s | 2 s | 0.6 s |
The exclusions decide the number
Two agreements quoting 99.99% can differ by hours of real outage, because availability is measured over whatever period the agreement says it is measured over. Planned maintenance windows, scheduled change freezes, outages attributed to the customer equipment and force-majeure events are commonly excluded, and each exclusion shortens the measured period without changing the headline.
Read the exclusion list before the percentage. A target of 99.9% with no exclusions is a stronger commitment than 99.99% with a weekly four-hour maintenance window, and the second one looks better in a table.
Why MTTR is the number that binds
Availability is often written as MTBF divided by the sum of MTBF and MTTR. Operators can rarely move MTBF — it is a property of equipment already bought — but MTTR is almost entirely operational: how fast an alarm is noticed, how fast the right person is reached, whether the spare is on site, whether the runbook matches the plant that was actually installed.
Once the annual budget drops below a single repair cycle, faster repair stops being the lever. At that point availability comes from the fault not reaching the user: independent A and B paths, automatic transfer, and a failover that has been tested under load rather than assumed.
What the percentage cannot express
- Shape. Fifty-two minutes as one outage during a trading peak is not the same event as fifty-two one-minute blips overnight, and the metric scores them identically.
- Blast radius. An outage affecting one rack and an outage affecting the whole hall both count as downtime.
- Correlation. Redundant components that share a root cause fail together; the arithmetic assumes they do not.
- Credit versus cost. Service credits are usually capped at a fraction of the monthly fee and rarely resemble the business impact of the outage.
Frequently asked questions
How much downtime is 99.9% uptime?
Three nines permits 8 hours 45 minutes of downtime per year, 43 minutes 48 seconds per month, or about 10 minutes per week, measured over a full 8,760-hour year with no excluded maintenance.
How many minutes per year is 99.99% uptime?
52 minutes and 33 seconds per year, which is about 4 minutes 22 seconds per month. At a four-hour mean time to repair that budget does not cover a single incident, which is why four nines is a statement about redundancy rather than repair speed.
What is the difference between 99.99% and 99.999%?
A factor of ten in permitted downtime: 52 minutes a year versus 5 minutes 15 seconds. Operationally the gap is larger than the arithmetic suggests, because five nines leaves no time for a human to be paged, arrive and diagnose — the recovery has to be automatic.
How do you calculate uptime percentage?
Divide the time the service was available by the total measured period and multiply by 100. If a service was down for 30 minutes in a 30-day month, that is 43,200 minutes measured and 43,170 available, giving 99.93%. Subtract any contractually excluded windows from the measured period first.
Does an Uptime Institute Tier rating guarantee an availability percentage?
No. Tiers describe topology and the maintainability that topology allows — concurrently maintainable, fault tolerant — and are awarded to a design or a facility, not to a service level. Availability percentages published alongside tier levels are industry folklore rather than part of the classification.
What MTTR do I need to hit my target?
Divide the annual downtime budget by the number of incidents you expect. At 99.99%, which is 52 minutes a year, and four incidents a year, each one has to be fully resolved in about 13 minutes including detection and dispatch — which usually means the answer is redundancy rather than speed.
Where this calculation stops
This converts a percentage into a time budget. It does not predict availability: that requires failure rates, repair distributions, dependency structure and a model of how components fail together.
Contractual availability and experienced availability are different measurements. A customer whose application depends on a single power feed inside a fault-tolerant facility experiences the availability of that feed.