A two-hour outage rarely costs only two hours of IT time. It can stop order entry, delay payroll, strand remote employees, interrupt customer service, and force managers into manual workarounds that continue long after systems come back online. To calculate business downtime costs accurately, look beyond the immediate repair bill and measure what the interruption does to people, revenue, operations, and customer confidence.

For a mid-market organization, this is not an academic exercise. A credible downtime figure helps leadership decide where to invest in backup systems, cybersecurity, cloud resilience, monitoring, support coverage, and disaster recovery planning. It turns a vague concern - “we cannot afford to be down” - into a number that can guide a practical decision.

Start With the Right Definition of Downtime

Downtime is any period when a business-critical technology service cannot perform its required function. That could mean a server outage, ransomware event, failed internet connection, unusable cloud application, phone system interruption, or network issue affecting one location.

The key phrase is business-critical. A printer issue affecting three employees is disruptive, but it does not carry the same cost as an outage that prevents 80 people from processing transactions. Likewise, a Microsoft 365 outage may be tolerable for an hour in one department but highly damaging if your customer service, sales, field teams, or finance operations depend on it.

Before assigning a dollar amount, identify the affected service, the people and processes that depend on it, and the duration of the impact. Also separate a full outage from degraded service. Employees working at half speed for a full day can create a larger loss than a short, complete outage.

The Core Formula to Calculate Business Downtime Costs

A useful starting formula is:

Downtime cost = lost productivity + lost revenue + recovery expense + additional business impact

This is intentionally straightforward. The value comes from using realistic inputs rather than pretending every interruption has one universal hourly rate.

1. Calculate lost employee productivity

Start with the number of employees affected, their loaded hourly cost, the percentage of productivity lost, and the length of the outage.

Lost productivity = affected employees × loaded hourly labor cost × productivity loss × downtime hours

Use loaded labor cost rather than base wages alone. Loaded cost includes wages, benefits, payroll taxes, and related employment costs. If you do not have an exact figure, your finance team can provide an average or reasonable estimate by department.

For example, suppose 60 employees are unable to use their core applications for three hours. Their average loaded cost is $48 per hour, and they are effectively 90% unproductive during the interruption.

60 × $48 × 90% × 3 hours = $7,776 in lost productivity

That figure can be too high or too low depending on the work. Some employees can make calls, work from mobile devices, prepare paperwork, or perform offline tasks. Others may be completely blocked. Use the actual level of interruption, not a worst-case assumption.

2. Measure lost or delayed revenue

For businesses that process orders, bill clients, schedule appointments, ship products, or handle customer transactions through connected systems, labor is only one part of the cost.

Calculate the revenue normally generated during the affected period. Then estimate how much is truly lost rather than merely delayed. A distributor that cannot process orders for two hours may catch up later. A medical practice that cannot access scheduling tools may lose appointments that cannot be recovered. An ecommerce company with a checkout failure may see customers abandon purchases permanently.

Lost revenue = average revenue per hour × outage hours × unrecoverable revenue percentage

If normal revenue is $18,000 per hour, an outage lasts two hours, and 35% of that revenue is likely unrecoverable, the estimated revenue loss is $12,600.

Be careful not to count total revenue as profit loss if you are evaluating the financial impact on the business. For a more conservative model, apply your gross margin. However, using revenue can still be appropriate when evaluating customer impact, cash-flow disruption, or the urgency of restoring a transaction system.

3. Include IT recovery and incident response costs

The visible repair effort has a cost too. This may include internal IT time, managed service support, emergency vendor support, overtime, forensic investigation, replacement hardware, data recovery, legal counsel, and communications support after a cyber incident.

For a routine outage, recovery cost may be limited to several hours of technical support. For ransomware, a failed server with no usable backup, or a network outage that requires onsite work, it can become a significant line item.

Include the costs that are specific to the event. Do not inflate the estimate by adding annual IT spending. The question is what the organization must spend because this interruption happened.

4. Account for operational and customer impact

Some costs do not fit neatly into payroll or revenue figures, but they are still real. Consider expedited shipping after a warehouse delay, late-payment penalties, production scrap, contractual service-level penalties, canceled appointments, lost billable hours, or a delayed close for the finance team.

Customer impact requires judgment. One brief outage may not change a relationship. Repeated outages in a competitive market can lead customers to question reliability, especially when they cannot place orders, reach support, or access a promised service. It is reasonable to include a conservative estimate of credits, churn risk, or sales opportunities lost because the interruption occurred.

Do not force a precise number where the evidence is weak. A range is often more credible: direct downtime cost of $25,000 to $40,000, plus possible customer-retention exposure. Leadership can make better decisions with an honest range than with a false sense of precision.

A Practical Downtime Cost Example

Consider a Connecticut-based professional services firm with 75 employees. A network and firewall issue prevents staff from reaching cloud applications and shared files for four hours. The company has a small internal IT team, but its managed IT provider is needed to troubleshoot the incident and coordinate with the internet carrier.

Fifty-five employees are materially affected. Their average loaded hourly cost is $55, and the firm estimates they are 80% unproductive. That produces $9,680 in lost productivity.

The outage also prevents consultants from recording billable work and delays a time-sensitive client deliverable. The firm estimates $6,000 in billable work will not be recovered. Emergency support and carrier escalation add $2,400. A client receives a $1,500 service credit because of the delay.

The direct estimated impact is:

  • Lost productivity: $9,680
  • Unrecoverable billable work: $6,000
  • Recovery and support: $2,400
  • Client credit: $1,500

Total estimated downtime cost: $19,580

That number changes the conversation. If a better firewall design, secondary internet connection, improved monitoring, or tested failover process costs less than the likely impact of one serious outage, it deserves consideration. The right choice still depends on risk tolerance, process criticality, and budget. Not every system needs the same level of redundancy.

Avoid the Most Common Calculation Mistakes

The first mistake is using headcount without asking who is actually affected. A payroll system outage might impact HR and finance immediately but not operations. A warehouse management outage might affect a smaller group of employees while stopping a large portion of daily revenue.

The second is treating all downtime as complete inactivity. Many teams can keep working in limited ways. Estimate the productivity loss by role and process where possible. This produces a more defensible result and helps identify practical workarounds.

The third is ignoring recovery time after systems are restored. Users may need to re-enter transactions, reconcile records, clear backlogs, reset passwords, validate data, or answer customer questions. A one-hour outage can produce several hours of follow-up work.

Finally, do not calculate only the average event. Your continuity planning should consider a likely short disruption and a less likely but more severe scenario such as a cyberattack, failed backup, or major infrastructure loss. Those events require different assumptions and different safeguards.

Use Downtime Costs to Set Technology Priorities

Once you calculate business downtime costs, apply the result to specific decisions. Which systems need documented recovery procedures? Where would a second internet circuit make sense? Are backups tested, not merely running? Can key employees work securely from another location? Does your team know who owns vendor escalation when a cloud platform, carrier, or critical application fails?

This process also clarifies the value of proactive support. Regular reviews of servers, endpoints, firewalls, network equipment, cloud services, and backup status can expose single points of failure before they become business interruptions. LANStatus helps organizations bring those pieces under one accountable support model, with recommendations tied to operational risk and budget rather than a generic upgrade schedule.

The goal is not to spend endlessly chasing zero downtime. That is rarely practical. The goal is to understand what an outage costs your organization, protect the systems that matter most, and make recovery predictable when disruption occurs. A clear number gives leadership a calmer, more useful place to start.

Managed IT is core to what we do. Let LANStatus keep your systems secure, supported, and running.

Explore Managed IT Services

Brian Diamond

Founder & CEO, LANStatus · Fractional Chief AI Officer

Brian founded LANStatus in 2001 and works with mid-market healthcare and financial-services organizations on AI strategy, governance, and security. He publishes The CAIO Brief, a weekly briefing for leaders navigating AI in real time.