What an Hour of Downtime Actually Costs You (And How to Work It Out)

Ask most business owners what an hour of systems downtime costs them and you'll get a shrug, or a guess, or a number that turns out to be the monthly IT bill divided by something.

It's an understandable blank. Downtime doesn't arrive with an invoice. Nobody sends you a bill for the orders that didn't get placed or the three hours twelve people spent waiting for the server to come back. The cost is real, it's often substantial, and it's almost entirely invisible unless somebody sits down and calculates it.

Which is a problem, because that number is the one that makes every other IT decision make sense. Whether to pay for redundancy, whether a four-hour recovery target is good enough, whether the managed service contract is expensive or cheap — none of those questions can be answered properly without it.

So let's work it out properly.

Why the industry benchmarks are useless to you

You'll find figures quoted everywhere. Gartner's often-cited $5,600 per minute.

Various vendor surveys landing somewhere between $100,000 and $500,000 per hour.

Ignore all of them. Those numbers come from large enterprises, and they're averages across industries with wildly different exposure. A trading platform and a landscaping firm do not lose money at the same rate, and neither resembles the average.

Your number is specific to your business, and the useful thing about calculating it yourself is that the exercise forces you to understand where the exposure actually sits. That's often more valuable than the final figure.

The four components

Downtime cost breaks into four parts. The first two are straightforward arithmetic. The third takes some thought. The fourth is the one everyone forgets and frequently the largest.

1. Lost productivity

The simplest component: people being paid to be unable to work.

Take your total annual payroll cost for affected staff — salary plus employer contributions, benefits, and overhead, not just gross salary. Divide by working hours per year (around 1,800 after holiday and leave) to get a fully-loaded hourly cost per person.

Then apply a productivity factor, because people are rarely 100% blocked. When the CRM goes down, sales can still make calls. When email fails, some work continues. A warehouse with no scanning system, by contrast, stops dead.

So: (number of affected staff × fully-loaded hourly cost × productivity loss percentage) × hours of downtime.

Be honest about the percentage. For a knowledge-work team with email and file access gone, 70–80% is realistic. For a system that only one department depends on, calculate that department separately rather than averaging across everyone.

2. Lost revenue

Only applicable if the outage actually prevents transactions — and this is where businesses often overstate things.

The question is whether revenue is lost or deferred. If your e-commerce site is down for three hours, some customers go elsewhere and never come back; that's lost. If your accounting system is down and invoices go out a day late, you're almost certainly getting that money anyway; that's deferred, and it costs you cash flow, not revenue.

For genuinely lost revenue: average revenue per operating hour × hours down × the proportion that doesn't recover.

That last proportion varies enormously. For a restaurant booking system on a

Friday evening, close to 100% — those covers are gone. For a B2B business with contracted clients, often close to zero; the work shifts to tomorrow.

Calculate at the right hour, too. Average revenue per hour understates a retail outage on a Saturday afternoon and massively overstates one at 3 a.m. on a Tuesday. If your business has peaks, model the peak, because that's when outages hurt and — through sheer load — often when they happen.

3. Recovery costs

The direct spend to get back up. Emergency IT support at out-of-hours rates. Overtime for staff catching up on backlog. Expedited hardware. Contractors brought in. Any data re-entry required.

This component is usually modest compared to the others, but it's real money that leaves the business, so it belongs in the calculation. One thing worth noting: recovery costs tend to be sharply non-linear. A one-hour outage costs almost nothing to recover from. A two-day outage can mean weeks of catch-up work.

4. The costs nobody counts

Here's where the picture usually changes.

Delayed work has a tail. When a team loses four hours, they don't lose four hours.

Deadlines slip, meetings get rescheduled, context gets lost, and the backlog creates its own friction for days. A reasonable rule of thumb from operations research is that recovery to normal throughput takes somewhere between one and two times the length of the disruption itself.

Customer trust erodes quietly. Nobody sends an email saying "I'm leaving

because your system was down." They just don't renew. A B2B client who can't reach your portal during their own busy period remembers that at renewal, and the lifetime value of one lost client often exceeds the entire direct cost of the outage that caused it.

Contractual penalties. If you have SLAs with customers, downtime may trigger service credits or penalties directly. Worth checking what you've committed to, because plenty of businesses have signed uptime commitments they've never measured themselves against.

Management attention. During a serious outage, your most senior people stop doing their jobs and start managing the crisis. That's the most expensive labour in the business, diverted to something that creates no value.

Compliance exposure. If downtime results from a security incident, the regulatory and notification costs sit alongside everything else.

A worked example

Take a 40-person professional services firm. Average fully-loaded cost of £55,000 per employee, which is roughly £30 per hour across 1,800 working hours. Annual revenue of £4.5 million.

Their main file server and email go down at 10 a.m. on a Tuesday. It takes six hours to restore.

Productivity: 40 staff × £30 × 75% blocked × 6 hours = £5,400

Revenue: billable work doesn't disappear — it gets done later. But around 15 client-facing hours are genuinely unrecoverable because consultants couldn't deliver scheduled sessions. At £120 per hour, that's £1,800.

Recovery: emergency support engagement plus four staff doing three hours of overtime catching up = roughly £1,400.

The tail: a six-hour disruption produces maybe eight hours of degraded throughput afterwards, at reduced impact — call it 25% across the team: 40 × £30 × 25% × 8 = £2,400.

Total: around £11,000 for a single six-hour outage. Just under £1,850 per hour.

Now the useful part. If this firm experiences two such incidents a year, that's £22,000 annually in losses they've never recorded anywhere. Against that, a resilience improvement costing £8,000 a year that prevents most of them is obviously worth doing — and that comparison is impossible to make without the number.

Turning the number into decisions

Once you have a per-hour figure, several previously fuzzy questions become straightforward.

Setting your recovery time objective. RTO is the maximum downtime you can tolerate. Businesses usually pick it by feel — "four hours sounds right." With a cost figure, you can set it where the cost of further reduction exceeds the cost of the downtime it prevents. Each step down in RTO gets more expensive; knowing your hourly cost tells you where to stop.

Evaluating redundancy spend. A failover system, a secondary internet line, or a hot standby server has a price. Compare it against expected annual downtime cost — frequency × duration × hourly cost — and the answer is usually obvious in one direction or the other.

Justifying the IT budget. This is the practical one. "We should spend more on infrastructure" is a weak argument. "Our two outages last year cost us £22,000 in lost productivity and client hours; this £8,000 change addresses the cause of both" is a different conversation entirely, and it's the one that gets approved.

Prioritising by system. Run the calculation per system rather than as one business-wide number. You'll usually find that one or two systems account for most of the exposure, and that's where resilience spending belongs. Protecting everything equally is both expensive and ineffective.

Checking your insurance. Business interruption cover often has a waiting period — commonly 8 to 24 hours — before it responds. If your hourly cost is high and most of your incidents resolve within that window, the cover may be doing less than you assumed.

Measuring it going forward

The estimate is a starting point. It gets more useful when you track reality against it.

Start logging incidents in whatever form is easiest: date, system, start and end time, who was affected, what the knock-on effects were. A spreadsheet is fine.

After a year you'll have an actual frequency and duration profile instead of a guess, and your calculation becomes grounded.

While you're at it, note the cause of each incident. Most businesses discover the same root cause recurring — an ageing server, a flaky internet connection, a single point of failure nobody got round to addressing. The pattern is usually more actionable than the total.

The point of the exercise

Downtime is the clearest example of a cost that businesses carry without ever seeing. It doesn't appear in the accounts. It doesn't get discussed at board level unless it's severe. And because it's invisible, it loses every budget argument to costs that are visible — which is how organisations end up running critical operations on hardware they'd never consciously choose to depend on.

Putting a number on it doesn't automatically mean spending more on IT. Sometimes the calculation shows your current arrangement is perfectly proportionate, and that's a genuinely useful thing to establish.

But it moves the conversation from instinct to arithmetic. And in a decision about how much resilience to buy, arithmetic is a much better guide than the memory of how stressful the last outage felt.

At Lunara Limited, we help businesses work out their real downtime exposure and then address the specific systems driving it — rather than spending evenly across everything. If you've had more than one unplanned outage this year and couldn't say what they cost, that's the place to start.