What an hour of downtime actually costs — and how to shrink it

Downtime feels like an abstract risk right up until the moment it isn't — so it helps to put an honest dollar figure on it before the outage does it for you.

When a server, a network link or a critical line-of-business app goes down, the cost isn't one number — it's four stacked on top of each other. Most owners only see the first one. Here's a simple way to add up all four, a worked example, and the handful of fixes that actually move the total.

A simple formula for the cost of an hour

You can estimate the cost of an hour of downtime without a spreadsheet full of assumptions. Add up four buckets:

• Idle staff cost — the people who can't work, valued at their fully loaded hourly cost (wage plus benefits and overhead), multiplied by how many are blocked.
• Lost revenue or throughput — sales you don't make, jobs that don't ship, or billable hours you can't invoice during the outage.
• Recovery cost — the after-hours work, emergency support, overtime and rework needed to catch back up once systems return.
• Reputation — the harder-to-measure cost of a customer who couldn't reach you, a missed deadline, or a client who now wonders whether you're dependable.

The first three are easy to estimate. The fourth is the one that occasionally dwarfs the others — and it's the reason you don't want your first serious outage to be on a day that matters.

A worked example: a 50-person BC business

Picture a 50-person professional-services firm in the Lower Mainland. Say their fully loaded staff cost averages $55 an hour, and a systems outage blocks 40 of them from real work.

• Idle staff: 40 people × $55 = $2,200 per hour.
• Lost throughput: if those 40 are billable and can't bill, that's another large chunk on top — easily matching or exceeding the idle-cost figure.
• Recovery: a half-day of catch-up and a vendor's emergency call-out can add a few thousand more, spread over the following days.

Even on conservative assumptions, you're well past $4,000–$6,000 for a single hour — and a serious outage rarely lasts one hour. A morning lost to a failed server can quietly cost more than a year of doing the prevention properly.

The expensive part of downtime is almost never the broken hardware. It's the fifty people standing around waiting for it.

Why outages happen — the usual culprits

In small and mid-sized businesses, the same two stories come up again and again:

Aging single servers

One physical server, bought years ago, quietly running the thing the whole business depends on — the file share, the accounting database, the booking system. There's no second one to fail over to. When the power supply, the disk or the motherboard finally goes, everyone stops at once. That's a single point of failure, and it's the most common one we find.

Untested backups

Backups that have been "running" for years but that nobody has ever actually restored from. A backup you haven't tested isn't a backup — it's a hope. The worst time to discover the job has been silently failing, or that the restore takes three days, is the morning you need it.

The fixes that move the number most

You don't need to gold-plate everything. A small number of high-leverage changes shrink your downtime exposure dramatically:

1. Monitoring. Catch the failing disk, the full drive, the dying battery before it takes everything down. Most outages announce themselves days in advance — to anyone who's watching.
2. Remove single points of failure. Redundant power, a second internet connection, a failover for the one server everyone depends on. The goal is that no single device failing can stop the whole business.
3. Tested restores. Don't just take backups — periodically restore from them and time it. That turns "we think we're covered" into "we know we can be back in two hours."
4. Patching and lifecycle. Keep systems updated, and retire hardware before it ages into the danger zone rather than after it fails.

This is the quiet, unglamorous work that good managed IT does in the background — the monitoring alert handled before anyone notices, the restore tested last quarter, the second server that means a failed component is a shrug rather than a crisis. It's exactly the kind of thing you only appreciate by its absence. For real examples of how this plays out for BC businesses, see our case studies.