Ask a business owner what an hour of downtime costs and you will usually get a shrug, followed by a guess that is too low by a factor of three or four.
That matters, because almost every decision about resilience — better backups, a second internet line, faster support cover — is a comparison between a known cost and an unknown one. When the unknown side stays unknown, the known side always looks expensive.
So here is how to work yours out.
The simple version
The floor of the calculation is straightforward: people who cannot work, multiplied by what their time costs, multiplied by how long it lasts.
The hourly cost per person is their annual salary divided by roughly 1,950 working hours. On a £38,000 salary that is around £19.50 an hour — and remember that what the business pays is closer to 20% more than the salary once employer’s National Insurance and pension are included.
What an hour of downtime costs you
Move the sliders. Nothing is sent anywhere — this runs entirely in your browser.
What the number above leaves out
Everything in that calculator is staff time. It is the most defensible figure and the least complete one.
Revenue you cannot take. If orders arrive through a system that is down, that is not deferred income, it is frequently lost income. Customers go elsewhere.
The catch-up. Work does not resume at normal pace afterwards. There is a backlog, and a period where everyone is working through it rather than doing new work.
Rework. Anything in progress when systems went down often has to be redone, and the version that gets redone is usually worse.
Customers who noticed. Hardest to quantify and frequently the most expensive. A missed deadline with a major client can cost more than every hour of lost staff time combined.
The recovery itself. Engineering hours, overtime, occasionally specialist incident response — particularly if the cause was ransomware rather than a failed disk.
Why most businesses underestimate it
Three reasons, consistently.
People count only the obviously idle. If email is down, the assumption is that everyone will get on with something else — and to a degree they do, which is why the calculator above defaults to 70% rather than 100%. But the work they switch to is rarely the work that mattered.
People think about average outages rather than the bad one. The relevant figure for planning is not the twenty-minute blip; it is the two days it takes to restore from backup when a server fails on a Friday afternoon.
And people forget the tail. A four-hour outage produces roughly a day of disruption once the backlog, the rework and the chasing are counted.
What to do with your number
Once you have it, most resilience decisions answer themselves.
Compare it against what you currently spend on backup and monitoring. If a single day of downtime costs several times your annual spend on preventing it, the balance is wrong — and that is a remarkably common finding.
Then ask the more useful question: how long would we actually be down? Not how long the backup takes to restore in theory. How long from the failure to people working again, including the time before anyone noticed, the time to diagnose, and the time to verify that what came back is correct.
Most businesses have never measured this, and the estimate is usually optimistic by a wide margin. The only way to know is to test it.
The uncomfortable follow-up
If you have a backup you have never restored from, your real recovery time is unknown rather than short. If nobody monitors whether backups completed, it may be considerably longer than unknown.
We test restores for clients as a matter of routine, and the first test on a newly inherited estate turns up a problem more often than not. It is a better morning to find that out on than the alternative.
If you would like to know what your genuine recovery time is — rather than the one on the documentation — that is a straightforward thing for us to establish.
