The real cost of one hour of downtime

When the ERP server goes down or company email stops sending and receiving, the first question is usually "when will it be back up?". The less-asked but equally important question is: how much money does each hour like this cost the business?

Without that number, every infrastructure investment decision (a standby server, a monitoring service, an SLA contract) is made by gut feeling: you either spend too little and pay the price when an incident hits, or spend too much on risks that do not matter. This post gives you an estimate that is simple enough for the CFO and the IT manager to work through together in one sitting.

The downtime cost formula

The cost of one hour of downtime breaks into four groups:

Downtime cost = Lost revenue + Lost productivity + Recovery cost + Other knock-on costs

1. Lost revenue

• Revenue per hour = Annual revenue ÷ Operating hours per year

• Revenue lost per hour = Revenue/hour × Share of revenue that depends on the system × Share that cannot be recovered

The last two ratios matter most. Not every outage loses all revenue, and not every delayed order is lost for good. Many customers will wait a few more hours; some will switch to another supplier.

2. Lost productivity

• Productivity lost per hour = Affected staff × Average fully-loaded cost per staff-hour × Impact (%)

Cost per staff hour should be calculated in full: salary, insurance, allowances, benefits — not just base pay.

3. Recovery cost

IT team overtime, emergency support fees from vendors, replacement parts, and the manual re-entry of data after the system is back up.

4. Other knock-on costs

Late-delivery penalties under contract, urgent freight to rebuild the schedule, and the hardest part to quantify: your reputation with customers and partners.

A worked example (illustrative figures)

Note: every figure below is hypothetical, to illustrate the math — not data from any specific business.

Imagine a trading company with annual revenue of VND 120 billion, working roughly 2,400 hours a year. Its ERP system (ordering, warehouse, invoicing) goes down for 4 hours on a Monday morning.

That figure excludes late-delivery penalties and customers who never come back. The notable insight is that the "unrecoverable" ratio dominates the result: at 10% of revenue lost for good, the hourly cost drops to about VND 5.2M; at 50%, it climbs to about VND 17.2M. So sit down with the sales team to estimate that ratio instead of letting IT guess.

What makes downtime costs spike

• When it happens. An outage during month-end close, peak season or right before the tax filing deadline costs far more than one on a Saturday afternoon.

• Time to detection. If you only learn about the incident when users call to complain, the business has already lost 30–60 minutes before response even starts.

• Cascade effects. ERP down means the warehouse cannot ship, delivery trucks wait, accounting cannot issue invoices.

• Data loss. Downtime is not the same as data loss. When the newest backup is a day old, every transaction of that day has to be re-entered.

• No process. When nobody knows who to call, where the admin passwords are or which vendor owns which device, the outage lasts far longer than it should.

How to reduce downtime cost

Real downtime has four segments: detect → diagnose → fix → verify back online. Each measure below shortens one or more of them.

24/7 monitoring: shorten detection

A monitoring platform checks servers, services, disk capacity, SSL certificates and links on a schedule, and alerts the moment something drifts. Many issues can be resolved before users ever notice — a disk about to fill up, a certificate about to expire.

Redundancy: reduce frequency and blast radius

Dual power and UPS, two internet links from two carriers, RAID for disks, clusters or VMs that can move to another host. You don't need to duplicate everything — prioritise the systems with the highest downtime cost from the calculation above.

Runbooks: shorten diagnosis and recovery

A runbook is a step-by-step document for recurring situations: restarting services in the right order, failing over to the standby link, restoring from backup. A good runbook lets the on-duty engineer resolve the incident even when the one person who knows the system best is on leave.

SLA: turn expectations into commitments

A clear SLA contract defines response times, resolution times by priority level and service availability. To understand what the percentages really mean, convert them into time:

When you read an SLA, look past the percentage. Ask: is it measured monthly or yearly, is planned maintenance excluded, and what is the remedy when it is breached?

Checklist: measure and reduce downtime cost

• [ ] List your 5–10 most critical systems (ERP, email, file server, website, accounting software…)

• [ ] For each system, estimate the revenue share it supports, with the sales team

• [ ] Compute the average cost per staff-hour (including insurance and benefits)

• [ ] Rank systems by downtime cost per hour

• [ ] Check which systems are automatically monitored today and which are not

• [ ] Identify the single points of failure of the top 3 systems

• [ ] Write runbooks for at least 3 common incident scenarios

• [ ] Review your existing SLA: response time, resolution time, exclusions, remedies

Start from your own numbers

Your downtime cost figure does not need to be exact; it needs to be good enough to compare against the cost of prevention. If you would like someone to review your current infrastructure, identify which systems carry the most risk and where investment should go first, the SYSMAN team can run an assessment session with you. Send a request through our contact page.