Downtime Cost Calculator and Recovery Target Check
Put a number on an outage before you set recovery targets. Enter the revenue at risk, the people affected and how long systems would be down. See revenue exposure and labor impact as separate lines, what a recovery target would avoid, and how it adds up over a year.
How much does downtime cost?
Downtime costs two different things at once: revenue you cannot take or bill, and wages paid to people who cannot work. Multiply each by the hours down, keep them on separate lines, then add recovery fees and re-entry time as their own items. This calculator does that with your numbers and shows what a shorter recovery target would avoid.
How is the cost of downtime calculated?
The cost of downtime is the value lost or spent while a system, line or office cannot work, over the hours it is down. The calculator uses four steps:
- Revenue exposure per hour. The sales, billings or production value you cannot take, ship or bill in an hour without the affected systems. If the business can catch up later, this is delayed revenue, not lost revenue, and you may choose to leave it out or discount it.
- Labor impact per hour. Affected staff multiplied by their loaded hourly cost (wages plus payroll taxes and benefits, divided by hours worked). This is the cost of paying for hours that produce nothing, so it applies even when revenue is only delayed.
- Per event and per year. Each hourly figure is multiplied by the disruption duration, and then by how often such an outage might happen, using your own incident history rather than an industry average.
- Versus the recovery target. The same math runs again with the shorter of your RTO and the disruption. The difference is what recovering inside the target would avoid in this scenario.
For production or machine downtime in manufacturing, use the output value the line would have produced per hour as the revenue at risk and the idle crew as the affected staff; restart scrap, expediting and overtime go on their own lines in the exported CSV. The export lists every input and output so you can add items the tool does not calculate: recovery fees, penalties, customer loss and the re-entry work set by your RPO.
Use the business continuity plan template to record the impact per process
What do RTO and RPO mean here?
RTO, the recovery time objective, is the longest a system can stay down after a failure before the business is harmed. It is met by how fast you can restore or fail over. RPO, the recovery point objective, is the most data you can afford to lose, measured as the time between the last good copy and the failure. It is met by how often you copy the data. Both are defined this way in NIST's contingency planning guide, SP 800-34 Rev. 1 (checked on November 7, 2026).
A note on the abbreviation: "RTO" is also used for unrelated things, including return to office, rent to own and, in computing, a real-time operating system. On this page and in the calculator it means only the recovery time objective. Searching for an "RTO calculator" sometimes returns those other meanings; if you reached this page looking for one of them, it will not help.
The calculator prices downtime, which is the RTO side. The RPO side costs money as re-entry work: if the last good copy is four hours old, someone re-keys four hours of orders or records after the restore. To include it, add those hours to the labor line or as a separate row in the export. Our guide to RTO vs RPO has a worked example and typical tiers, and the glossary defines RTO and RPO.
A calculated target is not a tested restore time
The RTO you type here is a target: what the business would like. What your backups, runbook and people actually deliver is a measured result, found by restoring the system on an isolated network and timing every step from the moment the plan starts the clock to users working. The two often differ by hours, usually because of a missing password, a license key, an undocumented dependency or a backup that was never restored. Treat the avoided-cost line as the value of closing that gap, not as evidence that the gap is closed. How to test a disaster recovery plan covers the five kinds of test and what to record.
Assumptions
- Every number comes from you. The tool has no defaults, no industry averages and no NetSys prices; the placeholders are examples of the kind of figure to enter.
- Revenue at risk and labor impact are kept on separate lines; the only combined figure is labeled as a sum of the two.
- Hourly figures are assumed constant across the disruption. A real outage at 2 a.m. costs less per hour than one at 10 a.m.; enter an hourly rate that fits the scenario you are planning for.
- Implied availability is measured against 8,760 calendar hours. Against operating hours only, the same downtime is a larger percentage.
- Not calculated: data re-entry, recovery and forensic fees, overtime, contractual penalties, fines, lost customers and reputational effects.
Recovery design, backups and failover for the systems the business stops without are described on the disaster recovery services page, including how recovery tiers get their RTO and RPO and how each is tested.
Downtime cost calculator questions
How do you calculate the cost of downtime?
Separate the two kinds of loss. Revenue exposure is the revenue you cannot take or bill per hour, multiplied by the hours down. Labor impact is the number of people who cannot work, multiplied by their loaded hourly cost and the hours down. Add recovery fees, overtime, penalties and re-entry time as their own lines. Only then add the lines, and label the total as a sum of estimates.
What is the downtime calculation formula?
Cost per hour = hourly revenue at risk + (affected staff x loaded hourly cost). Cost of one outage = cost per hour x hours down. Annual exposure = cost of one outage x outages per year. Downtime percentage = downtime hours / total hours in the period x 100, and availability is 100 minus that. This tool runs those formulas on your numbers and keeps the revenue and labor parts visible.
How do I calculate the cost of production or machine downtime in manufacturing?
Use the value of output the line would have produced per hour as the hourly revenue at risk, and the crew that stands idle as the affected staff. Add restart scrap, expediting and overtime as separate lines in the exported file. If the plant can catch up later with overtime, the revenue line is a delay rather than a loss, so record it that way.
Is this an RTO calculator?
It is a recovery target check, not a tool that picks your RTO for you. You enter the recovery time objective you are considering and the tool shows the exposure if systems came back inside that target compared with the full disruption. The right RTO comes from the business impact analysis for each process, and whether you can meet it is proved only by a timed restore test.
What is the difference between RTO and RPO?
RTO, the recovery time objective, is how long a system can be down before the business is harmed; it is met by how fast you can restore or fail over. RPO, the recovery point objective, is how much recent data you can afford to lose, measured as time since the last good copy; it is met by how often you copy data. This tool prices downtime (RTO). Data loss (RPO) shows up as re-entry hours, which you can add as labor.
Why does the tool show revenue and labor separately instead of one total?
Because they are different kinds of loss and are often double counted. Revenue lost during an outage may be delayed rather than gone, and staff still get paid whether or not the systems work, so the labor line is the cost of paying for hours that produced nothing. Showing them apart lets you decide which applies, and the sum row is labeled as a sum so nobody mistakes it for a measured loss.
Is the result a NetSys price or guarantee?
No. Every figure comes from the numbers you enter; NetSys sees none of them. The result is a planning estimate to help you set recovery priorities and compare the cost of an outage with the cost of faster recovery. Recovery services are quoted separately after a review of the systems, backups and dependencies.
A recovery review looks at the systems your business stops without, the backups and copies you have today, the order they would come back in and the restore times you can prove. You leave with written targets per system and a test plan, which you can run with any provider.
Request a recovery review