Availability calculator: convert percentages and downtime
Allowed downtime comes from a single calculation: downtime = period × (100% − availability). Enter a percentage below to see the downtime it allows per year, month, week and day. The reverse calculation turns the downtime you can tolerate into the availability percentage you need.
Germany's Federal Office for Information Security (BSI) defines availability as the probability that a system meets all of its assured properties at any given point in time. In practice, it is quoted as a percentage.
Downtime table: from 99% to 99.999% availability
At 99.99% uptime, downtime per year is capped at 52.6 minutes; at 99.9%, it is 8.76 hours. Each additional nine cuts the allowed downtime by a factor of ten. The table lists the nines of availability that come up in practice, per year, month, week and day.
| Availability | per year | per month (30 days) | per week | per day |
|---|---|---|---|---|
| 99% | 87.6 h (3.65 days) | 7.20 h | 1.68 h | 14.4 min |
| 99.5% | 43.8 h | 3.60 h | 50.4 min | 7.20 min |
| 99.9% | 8.76 h | 43.2 min | 10.1 min | 1.44 min |
| 99.95% | 4.38 h | 21.6 min | 5.04 min | 43.2 s |
| 99.99% | 52.6 min | 4.32 min | 1.01 min | 8.64 s |
| 99.999% | 5.26 min | 25.9 s | 6.05 s | 864 ms |
Convention: one year = 365 days, one month = 30 days, operation around the clock. The BSI uses 365.25 days in its examples, which gives 8.77 rather than 8.76 hours for 99.9%. Values rounded to three significant digits. As of October 2026.
Availability classes defined by the BSI
In its high availability compendium, the BSI groups availability into six classes, abbreviated VK for Verfügbarkeitsklasse and separated by the number of nines. The downtime figures assume operation 24/7; the class names are our translation of the German original.
| Class | Name | Minimum | Downtime per month | per year |
|---|---|---|---|---|
| VK 0 | No guaranteed availability | no percentage given | ||
| VK 1 | Normal availability | 99.0% | < 8 h | < 88 h |
| VK 2 | Increased availability | 99.9% | < 44 min | < 9 h |
| VK 3 | High availability | 99.99% | < 5 min | < 53 min |
| VK 4 | Highest availability | 99.999% | < 26 s | < 6 min |
| VK 5 | Availability under extreme conditions, including force majeure (disaster tolerant) | no percentage given; according to the BSI, downtime can hardly be predetermined | ||
Source: BSI, HV-Kompendium V 1.6, Volume G, Chapter 2, Table 3 (2013, in German). The compendium has been withdrawn; Volume G remains published for information.
High availability: definition and threshold
Under the BSI classification, high availability usually starts at availability class 3: 99.99%, or less than 53 minutes of downtime per year. Systems in this class are available almost continuously. According to the BSI, ordinary measures are not enough to get there; it takes automated monitoring and recovery combined with redundancy that is ready to take over.
The classes describe requirements for a business process or a system; they are not a quality seal for a platform. Which class a process needs depends on the consequences of an outage: what an hour of downtime costs and any legal or safety requirements. For related terms, see the glossary in our knowledge section.
Not to be confused with availability classes under EN 50600
The European data center standard EN 50600 (DIN EN 50600 in Germany) also defines four availability classes. According to CEN-CENELEC, they classify the design of a data center's power distribution, environmental control and telecommunications cabling, not the availability of the service running there. A class under EN 50600 therefore does not correspond to the BSI class of the same number, and on its own it says nothing about the availability of your application.
What percentages hide: measurement point, period, maintenance, partial outages
An availability percentage only means something once you know how it is measured. Two figures with the same percentage can be very different commitments: what matters is the measurement point, the measurement period, how planned maintenance is treated and whether partial outages count. These five questions clarify any availability figure, whoever states it.
| Question | Why it changes the number |
|---|---|
| Where is it measured? | A server can be up while the application fails to respond. Measuring at the server, at the network edge or from the user's perspective produces different figures. |
| Over which period? | 99.9% per year permits one 8.76-hour outage; measured per month, no month may exceed 43.2 minutes. |
| Does planned maintenance count? | If maintenance windows are excluded, real-world uptime can fall well below the stated figure. |
| What counts as an outage? | Partial outages such as a broken checkout or badly degraded response times only count if the definition covers them. |
| How often, and for how long? | The same figure can mean one long outage or many short ones, a substantial difference for business processes. |
The BSI adds two caveats. The one-year observation period common in contracts hardly provides statistical significance, so a year without an outage is not proof of high availability. And depending on whether planned maintenance, logistics and administration count as downtime, there are several definitions of availability; where an agreement leaves this open, false expectations are common.
That is why our operations include health checks from the user's perspective, which test whether your application responds rather than only whether its processes are running. For more questions on contracts and service levels, see our managed hosting provider checklist.
Downtime cost: what an hour of outage costs you
How much availability you need is above all a business question: what does an hour of downtime cost you? To calculate downtime cost, multiply the hours of downtime by your lost revenue and staff cost per hour, then add follow-on costs such as contractual penalties. The inputs come from your own business; there are no universal benchmark figures.
Downtime cost = hours of downtime × (lost revenue per hour + staff cost per hour) + follow-on costs
| Variable | What goes into it |
|---|---|
| Hours of downtime | Expected downtime in the period you are looking at, for a year taken from the table above. |
| Lost revenue per hour | Revenue or contribution margin that is actually lost; some customers simply order later. |
| Staff cost per hour | Working time of employees who cannot work or have to redo work. |
| Follow-on costs | Contractual penalties, data recovery and customer communication in the same period. |
The value of higher availability shows in the gap between two targets. The gap between 99.9% and 99.99% is 7.88 hours of downtime per year. Multiply that by your cost per hour of downtime and you know what the extra nine is worth each year; weigh it against the added cost of redundancy.
An hour of downtime at night often costs less than one at peak business time. Also count the time until full recovery, including data reconciliation and rework.
Where availability comes from: series, redundancy, recovery
The availability of an IT system is a product of its architecture, above all of redundancy. Every component your application cannot run without lowers overall availability; every component that can stand in for a failed one raises it. This leads to two calculation rules, which the BSI describes for independent failures: one for series, one for redundancy.
In series: the chain is weaker than its weakest link
When several components all have to work, their availabilities multiply: A = A1 × A2 × … × An. Two components at 99.9% each combine to 99.8%, or 17.5 hours of downtime per year. The BSI shows that a component at 99.99% in series with one at 99% reaches only about 98.99%. The chain is weaker than its weakest link.
Redundant: a total outage takes several failures at once
When one of several components is enough, the whole only fails if all of them fail at the same time. The failure probabilities then multiply: 1 − A = (1 − A1) × (1 − A2). On paper, two nodes at 99% each reach 99.99%.
Diagram as text
- In series: component A and component B must both run, each at 99.9%. Overall: 0.999 × 0.999 is about 0.998, which means 99.8% or 17.5 hours of downtime per year.
- Redundant: node 1 and node 2 each have 99%, and one of them is enough. Overall: 1 − 0.01 × 0.01 equals 0.9999, which means 99.99% or 52.6 minutes of downtime per year.
- Both calculations assume that failures are independent of each other; the redundancy calculation also assumes that switching over takes no time.
Both rules assume independent failures; the redundancy rule also assumes a switchover that takes no time. In practice, a shared power circuit, a faulty update or an operator error can hit redundant components at the same time, so redundancy has to cover every layer, from the network to storage.
What this means for a Proxmox cluster
The BSI names two levers for higher availability: extending the mean time until a failure occurs (MTTF, mean time to failure) and shortening the mean downtime (MTTR, mean time to repair). Availability is the ratio of the two: A = MTTF ÷ (MTTF + MTTR).
The HA Manager in a Proxmox cluster works on the second lever, downtime. If a node fails, the Proxmox HA Manager automatically restarts the affected virtual machines on another node. Services running on several nodes behind the load balancer remain available.
The load balancer removes a failed node from rotation within seconds. The node's virtual machines restart on another node after fencing; how long that takes depends on fencing and on the guest system's boot time.
So if your application runs in a single virtual machine, a failure of the node it is running on counts as downtime until fencing and restart are complete. How quorum, fencing and the HA Manager work together is covered on our high availability cluster page; why a cluster needs at least three nodes or an external quorum device for this is explained in the guide to split brain, quorum and fencing.
A high availability cluster is not a backup.
Replication also copies accidental deletions, faulty updates and encrypted data to every copy. How fast you need to be back in business, and with which data, is set by RTO and RPO: the recovery time objective and the recovery point objective.
Our commitment: the availability target is written into the operations contract
We do not promise blanket nines; the target is written into the operations contract. At managed-cluster.net, we set the availability target for every managed Proxmox cluster together with you, based on your application and the level of redundancy in its architecture. Your downtime cost, meaning what an hour of outage costs you, is a solid basis for that decision.
Besides the availability target, the contract covers response times by priority level, service hours and escalation paths, and the recovery objectives RTO and RPO. For an overview of what the operations contract covers, see our operations and monitoring service. Critical alerts reach on-call duty immediately and are handled right away, around the clock.
- Evidence: Every managed cluster comes with a monthly operations report covering availability, incidents and utilization. The Business package adds SLA reports and extended monitoring with escalation.
- Incidents: For every incident, you receive a post-incident report with the cause and the measures derived from it.
- Tests: Before go-live we test failover in full, and regularly afterwards with a written record, on a schedule agreed with you (failover testing and runbooks).
- Maintenance: We apply updates node by node while your systems keep running. Exceptions such as a major database upgrade are announced in advance and scheduled in a window you choose.
How we put this into practice
High availability in a managed Proxmox cluster
Three nodes as standard with quorum and fencing against split brain, 24/7 monitoring with on-call duty and, in the Essentials and Business packages, Ceph storage with three replicas of every data block on different nodes.
Redundancy at every layer of a high availability cluster