The honest answer to “what does an hour offline cost us?” is: more than you think, and you can work it out in ten minutes. Take the staff who can’t work, multiply by their loaded hourly cost and the hours lost, then add the revenue you didn’t earn and the cost of putting things right. That number is usually a nasty surprise.
Most owners have never run that sum. They have a vague sense that downtime is bad, but no figure to weigh against the cost of preventing it. That gap is exactly why “we’ll fix it when it breaks” feels cheaper than it is. Here’s how to calculate the real cost of downtime for your business, what people leave out, and why a proactive approach almost always wins on the numbers.
The simple formula
You don’t need a consultant or a spreadsheet model to get a defensible figure. Four buckets cover most of it.
- Lost productivity = staff affected x loaded hourly cost x hours down. The people who are sitting idle, or working at half pace, while the system they need is unavailable.
- Lost revenue = sales, billable hours or transactions you couldn’t process during the outage and won’t recover later. Not every business has this; a retailer with the till down clearly does.
- Recovery costs = the after-hours engineering, overtime, expedited hardware, and the catch-up work once you’re back. This is the bit that keeps running after the lights come back on.
- Intangibles = reputation damage, missed deadlines, SLA penalties you owe your own clients, and the goodwill you spend apologising. Hard to price exactly, real all the same.
Add the four together and you have your cost per hour of downtime. The first bucket is the one everyone can calculate, so start there.
Getting “loaded hourly cost” right
A common mistake is to use the raw wage. The figure you want is the loaded cost — salary plus superannuation, payroll tax, leave loading, and overheads like the desk, the laptop and the software licence that person needs to do their job. As a rough rule, loaded cost runs about 1.25 to 1.4 times base salary. Someone on $90,000 isn’t costing you $43 an hour when they’re idle; they’re closer to $55 to $60 once you load it properly. Use the loaded figure or you’ll undercount every time.
A worked example
Let me put real numbers to it. This is a deliberately hypothetical scenario, not a real client and not a statistic — but the assumptions are the kind we see in Melbourne SMEs every week. You should swap in your own figures.
Picture a 30-person professional services firm in Camberwell. Their line-of-business application and shared files go down for half a day — four working hours — because a server failed and there was no quick failover. Assumptions:
- 25 of the 30 staff are completely blocked; the other five can do offline admin.
- Average loaded hourly cost across the affected staff: $60.
- The firm bills time, and roughly $8,000 of billable work for that morning simply can’t be done and largely can’t be clawed back.
- Recovery: an after-hours engineer, a replacement part couriered in, and overtime to catch up — call it $3,500.
| Cost bucket | Calculation | Amount |
|---|---|---|
| Lost productivity | 25 staff x $60 x 4 hours | $6,000 |
| Lost revenue | Unrecoverable billable work | $8,000 |
| Recovery costs | After-hours labour, part, overtime | $3,500 |
| Intangibles | Two client deadlines slipped; one annoyed client | Not priced, but real |
| Total (measurable) | $17,500 |
That’s $17,500 for half a day, before you count the intangibles. Spread the same event across a few times a year and you’re well into five figures of avoidable loss. Run those four lines for your own business with your own headcount and rates — the exercise takes ten minutes and the result tends to change how people think about their IT budget.
The hidden costs people forget
The formula above captures the obvious losses. The ones that quietly inflate the real figure are easy to miss.
- The ramp-back-up tax. Productivity doesn’t snap back to 100% the moment systems return. People spend the next hour re-doing lost work, re-establishing context and clearing the backlog. Add 25 to 50 per cent to your productivity figure for this.
- Cascading effects. If your phone system, payment terminal or booking platform depends on the same internet link or server, one failure takes out several functions at once. The blast radius is usually wider than the thing that broke.
- SLA penalties you owe. If you have your own service-level commitments to clients, an outage can trigger credits or penalties. A logistics firm that misses a delivery window doesn’t just lose that job’s margin.
- Morale and overtime. Staff who lose half a day’s work then stay back to catch up don’t forget it. Chronic instability is a genuine factor in people leaving.
- Reputation. A retailer whose card terminal is down on a Saturday, or a clinic that can’t access patient records, loses trust as well as revenue. You can’t invoice for that, but you pay for it.
Why “fix it when it breaks” is a false economy
Break-fix — paying an hourly rate to fix things only once they fail — looks cheaper on a quiet month because you’re not paying for anything. The problem is what it does to both the frequency and the duration of downtime, which are the two levers that actually drive your cost.
Under break-fix, nobody is watching your systems. A failing disk, a backup that quietly stopped running three weeks ago, a firewall firmware bug — these get discovered when they cause an outage, not before. And when something does break, you’re at the back of the queue: the provider has to be called, has to understand an environment they don’t monitor, has to source parts cold. Your four-hour outage in the example above could easily have been an eight-hour one if the first two hours were spent just working out what failed.
The false economy is comparing the monthly fee of managed IT against zero, when the honest comparison is against the downtime you’ll eat without it. One avoided half-day outage a year often covers the difference.
How proactive managed IT cuts the bill
Good managed IT attacks downtime on two fronts: it makes outages less frequent, and it makes the ones that do happen shorter. Both reduce the hours in your formula.
Monitoring catches problems before they’re outages
Continuous monitoring means a failing drive, a service that’s stopped, or a backup job that didn’t complete raises an alert while it’s still a maintenance task, not an emergency. Most of the outages we prevent are ones the client never knew were coming. That’s the whole point — the cheapest downtime is the kind that never happens.
Redundancy removes single points of failure
A second internet service, a failover server, a clustered firewall — redundancy means one component failing doesn’t stop the business. It costs money, so you apply it where the downtime cost justifies it, which is exactly the calculation above. A business that knows an hour offline costs $4,000 can make a rational call on a $200/month redundant link.
Backups and a tested DR plan shorten recovery
When something does take systems down, the difference between a two-hour recovery and a two-day one is whether your backups work and whether you’ve ever actually tested restoring from them. An untested backup is a guess. We restore from backups on a schedule precisely so the day we need them isn’t the day we find out they were corrupt. A real backup and disaster recovery setup — with a documented, rehearsed DR plan — is what turns a catastrophe into an inconvenience. We go deeper on this in our guide to backup and disaster recovery for Melbourne businesses.
Tying downtime tolerance to RTO and RPO
Once you know what an hour costs, two numbers turn that into a design target. Your recovery time objective (RTO) is how long you can be down before the damage is unacceptable. Your recovery point objective (RPO) is how much data — measured in time — you can afford to lose. A business losing $4,000 an hour can’t tolerate a 24-hour RTO; the maths makes that obvious.
These aren’t abstract IT acronyms — they’re the bridge between your downtime cost and the money you should spend preventing it. Tight RTO and RPO targets cost more to deliver because they need redundancy and faster backups; loose ones are cheaper but expose you to bigger losses. The right answer falls out of the numbers you just calculated. Our explainer on RTO versus RPO walks through how to set them sensibly for each system.
TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers and no offshore helpdesk. We run per-user fixed monthly pricing with no hourly billing for in-scope work, and we target sub-15-minute response on critical issues from our 24/7 NOC in Tecoma — because on a P1, every minute is a line in the downtime sum above. If you’d like help working out what an hour offline genuinely costs your business and designing around it, get in touch and we’ll run the numbers with you.
Frequently asked questions
How do I calculate the cost of downtime for my business?
Add four buckets: lost productivity (staff affected x loaded hourly cost x hours down), lost revenue you can’t recover, recovery costs like after-hours engineering and overtime, and intangibles such as reputation and SLA penalties. Sum them for a cost per hour, then multiply by a realistic outage length. Use loaded staff cost — salary plus on-costs and overheads — not the raw wage.
What is loaded hourly cost?
It’s the true cost of an employee per hour, including superannuation, payroll tax, leave entitlements and overheads like their equipment and software, not just their base wage. It usually works out to roughly 1.25 to 1.4 times base salary. Using the loaded figure stops you undercounting your productivity losses.
Is managed IT actually cheaper than break-fix?
Over a realistic period, usually yes — because break-fix ignores the cost of downtime it fails to prevent. Managed IT reduces both how often outages happen and how long they last through monitoring, redundancy and tested backups. One avoided half-day outage a year commonly covers the difference in fees.
How do RTO and RPO relate to downtime cost?
Your downtime cost tells you how much an outage hurts; RTO and RPO turn that into design targets. RTO is how long you can be down, RPO is how much data you can lose. A high hourly cost demands tighter targets, which justify spending on redundancy and faster backups. The numbers should drive the design, not the other way round.
What are the hidden costs of downtime?
The ones people miss include the ramp-back-up time after systems return, cascading effects when one failure takes out several functions, penalties under your own client SLAs, staff morale and overtime, and reputation damage with customers. These often add as much again to the obvious productivity and revenue losses.