What an Hour of ERP Downtime Actually Costs

When an ERP system goes down, the instinct is to describe the damage in hours: "we were down for four hours." That's a duration, not a cost, and duration alone doesn't tell your leadership team or your insurer what actually happened to the business. Converting downtime into a dollar figure takes three more inputs: how much revenue flows through the business per hour, what share of that revenue is actually at risk during the outage, and what it costs to recover once systems are back up.

A worked example: a four-hour outage

A mid-sized distributor generates roughly $8,000 in revenue per hour during business hours. An ERP outage — a failed database migration during a routine patch, say — takes the order-entry and warehouse systems down for four hours. Not all of that revenue evaporates; some orders get taken by phone and entered later, some customers simply wait. The business estimates that 60% of normal productivity is lost during the outage window, and it takes a $12,000 emergency vendor engagement to restore service and validate data integrity afterward.

Revenue loss: $8,000 × 4 hours × 60% = $19,200
Total incident cost: $19,200 + $12,000 recovery = $31,200

A four-hour outage that might get described internally as "not a big deal, we caught up by end of day" cost this business over $31,000 once the lost productivity and the emergency recovery engagement are counted. Run your own numbers — your revenue per hour, your realistic productivity-loss percentage, and any recovery cost — with the downtime cost calculator.

Why productivity loss is never 100%, and rarely under 30%

Total revenue per hour overstates the damage, because businesses don't stop entirely the moment ERP goes down — phone orders, paper workarounds, and manual processes absorb some of the load. But it rarely drops as low as people hope, either. A realistic productivity-loss percentage depends on how central the ERP system is to the specific process affected: order entry and shipping tend to degrade sharply (60-80% loss) because there's no fast manual substitute at volume, while some back-office functions (reporting, budgeting) can often continue at near-normal productivity using cached data or spreadsheets for a few hours. Estimate productivity loss by process, not as one blanket number for the whole company, if you want a credible figure.

Recovery cost is more than the emergency vendor invoice

The $12,000 in this example covers an emergency support engagement, but a full recovery-cost estimate for a more serious incident should also include: data validation and reconciliation work after the system comes back (checking that no transactions were lost or duplicated), any customer-facing remediation (expedited shipping to make up for delayed orders, goodwill credits), and the internal overtime required to clear a backlog that built up during the outage. For a short, contained outage these add-ons might be minimal; for a multi-day incident they routinely exceed the emergency vendor fee itself.

Using this number for something other than a post-mortem

The real value of calculating downtime cost isn't describing what already happened — it's justifying what you spend to prevent it happening again. If a $31,200 outage happens two or three times a year, that's $60,000-$95,000 in annual downtime cost, which is a real budget line you can weigh against the cost of redundant infrastructure, a better-tested patching process, or a higher-tier support contract with faster response times. See our companion piece on building the business case for a tighter uptime SLA for how to turn this number into a specific infrastructure or contract decision.

What to track so this number gets more accurate over time

• Actual outage duration, measured from first impact to full restoration, not just "system back online"
• Which specific processes were affected, so productivity loss can be estimated per process rather than company-wide
• Every recovery cost — vendor fees, overtime, customer remediation — logged against the specific incident
• A running log of incidents over a year, so you can move from a one-off estimate to a real annualized downtime cost

A second scenario: a shorter but more disruptive outage

Duration isn't the only variable that matters — timing does too. Compare the four-hour outage above to a 90-minute outage at the same company, but one that happens during the last two hours of the month's order-processing cutoff, when nearly all normal activity is order-related and productivity loss runs closer to 90% rather than 60%, with a smaller $4,000 recovery cost since it resolved faster:

Revenue loss: $8,000 × 1.5 hours × 90% = $10,800
Total incident cost: $10,800 + $4,000 = $14,800

A shorter outage, but nearly half the cost of the longer one from the earlier example — proportionally more expensive per hour of downtime because it hit a moment when almost all business activity depended on the system being up. This is why "average cost per hour of downtime" is a useful planning number but a poor predictor of any single incident's actual cost — the same business can have wildly different downtime costs depending purely on when an outage happens, which argues for extra caution around scheduled maintenance windows, patch deployments, and upgrades: schedule them for the lowest-activity periods you can identify, not just "after hours" generically if your business has predictable peak windows within a day.

How this number should change your incident response priorities

Once downtime has a real dollar figure attached, it reframes internal conversations about incident response investment. A $15,000-$31,000 cost range for outages in the few-hours range makes a case for things that often lose out to other IT priorities in budget conversations: automated failover for critical services, a tested (not just documented) disaster recovery runbook, and a support contract tier with a faster guaranteed response time. Compare the cost of each of these investments against your own calculated downtime cost, the same way our companion piece on building the case for a tighter uptime SLA walks through — in most cases, the prevention investment is cheaper than a small number of avoided incidents.

Building a downtime cost log instead of a one-off estimate

The real power of this calculation comes from doing it every time, not once. A simple log — date, duration, affected processes, estimated productivity loss, recovery cost — turns a series of one-off "that was annoying" incidents into an annualized figure you can defend in a budget meeting and track year over year to see whether infrastructure investments are actually reducing cost, not just incident count.

Frequently asked questions

How do we estimate productivity loss percentage if we've never measured it before?

Start conservatively at 50-60% for customer-facing, transaction-heavy processes (order entry, shipping, invoicing) and 20-30% for back-office functions that can often continue with cached data or manual workarounds for a few hours. Refine the estimate after your next real incident by comparing actual output during the outage window to a typical period.

Should revenue per hour be calculated from annual revenue divided by business hours, or something more specific?

Business-hours-only division is a reasonable starting point, but refine it if your revenue is seasonal or concentrated in specific windows (a retailer's Saturday afternoon versus a Tuesday morning, for instance) — an outage during a peak revenue window costs meaningfully more than the same duration during a slow period, and your estimate should reflect when outages are actually more likely to hurt.

Does downtime cost calculation apply to planned maintenance windows too?

Yes, and it's an underused exercise — running the same calculation against a planned maintenance window's expected duration tells you what routine upgrades are costing the business, which is useful context for deciding whether to invest in zero-downtime deployment capability rather than accepting recurring planned outages as unavoidable.