Your figures
What downtime costs you
Every figure is computed only from your own inputs — so it’s exact for the numbers you entered, not a benchmark estimate of someone else’s business.
Put a real number on “the system’s down”
“We can’t afford downtime” is easy to say and hard to act on — until it has a figure attached. This calculator turns your own numbers into the true cost of an outage per hour, per incident and per year, so resilience spending becomes a simple comparison rather than a guess. It’s exact arithmetic on what you enter, not a borrowed benchmark.
The model — lost revenue plus lost productivity, scaled by outage length and frequency.
The two halves people underestimate
Lost revenue is your revenue-per-hour (annual revenue ÷ operating hours) — which is why a 24/7 operation feels an outage far harder than a 9–5 one. Lost productivity is the people who can’t work × their loaded hourly cost (salary plus on-costs, typically 1.25–1.4× base) × the share of their time that’s actually wasted. Add recovery, overtime and any SLA credits, and the per-hour rate is usually higher than the team assumes.
From cost-per-hour to an RTO/RPO you can defend
Once you know the hourly cost, your recovery objectives stop being abstract. Multiply it by your target RTO (recovery time) and you have the maximum loss a single incident should cause — and the most a faster DR solution needs to save to justify itself. Your RPO (recovery point — how much data you can lose) then sets how recent your backups must be. That’s how this number turns into a backup and disaster-recovery spec.
Then make the comparison
If a year of realistic outages costs more than resilient backup and DR, the business case writes itself. Pair this with the Microsoft 365 backup comparison for SaaS data, and the cloud vs on-premise TCO calculator when resilience changes where the workload should live.
⏱ Spend less than an outage costs. Servnet designs backup and disaster recovery around your RTO and RPO — so the resilience fits the risk. Plan your DR →
Cost of downtime — common questions
How is the cost of downtime calculated?
Two parts. Lost revenue: your annual revenue divided by the hours you operate gives a revenue-per-hour figure that stops during an outage. Lost productivity: the people affected × their loaded hourly cost × the share of their time that’s wasted while systems are down. Add an allowance for recovery, overtime and SLA credits, multiply by the outage length, then by how often it happens a year. Every figure here is yours, so the result is exact for your business.
What’s a “loaded” hourly cost?
Not just salary — the fully-loaded cost of employing someone per hour: salary plus employer NI, pension, software, overheads and so on. It’s typically 1.25–1.4× base salary. Using the loaded figure gives a realistic productivity-loss number rather than understating it.
Should I use 2,080 or 8,760 operating hours?
Use the hours your business actually depends on the systems. A 9–5, five-day operation is about 2,080 hours a year; a 24/7 service (e-commerce, manufacturing, hospitality) is 8,760. This sets your revenue-per-hour, so it materially changes the result — pick the one that matches when an outage actually hurts you.
How does this help me size backup and disaster recovery?
Once you know the cost per hour, you can put a number against your recovery objectives. Your RTO (how fast you must be back) multiplied by the cost-per-hour is the maximum loss a single incident should cause — and the most a DR solution needs to save to pay for itself. Your RPO (how much data you can afford to lose) frames how recent your backups must be. Suddenly “we need faster recovery” has a price tag attached.
What counts as “extra cost per incident”?
Everything beyond lost revenue and productivity: emergency engineering or overtime, data-recovery work, SLA penalties or service credits you owe customers, and — harder to quantify but real — reputational damage and lost orders. Even a conservative figure here makes the annual total more honest.
Is the result an estimate?
No — it’s exact arithmetic on the numbers you enter, not a benchmark borrowed from someone else’s business. The quality of the output simply depends on the quality of your inputs, so use realistic figures.
Most outages are short — does this still matter?
Yes, because they add up and the per-hour rate is often higher than people expect. Set a realistic outage length and frequency (including the small, frequent ones) and the annual total usually justifies far more spend on resilience than teams assume.