Downtime Cost Calculator

That means three things, and nothing else. First, revenue you did not earn because the service was down. Second, wages you paid to people who could not work. Third, the cleanup afterwards. Reputation damage and lost future customers are real, but nobody can calculate them honestly. So they are not in here.

Revenue per minute is the number everything else rests on

Start with revenue that genuinely depends on the service being up. Not total company revenue. If half your income comes from retainers that keep paying whether the site works or not, use the other half.

Then pick your earning window. A SaaS product earns around the clock, so its revenue spreads across all 525,600 minutes of the year. A B2B supplier taking orders during office hours does not. Choosing business hours makes each of those minutes worth more, not less, because the same revenue is packed into fewer of them.

Time to notice is part of the outage, not extra time on top

This trips people up. If your last outage ran ninety minutes and nobody spotted it for the first thirty, enter ninety and thirty. Not one hundred and twenty.

The detection figure is what the calculator uses to work out what monitoring is worth. Drop detection from thirty minutes to five, and the outage becomes sixty-five minutes instead of ninety. Same failure, less time bleeding.

Staff cost stays separate on purpose

Leave the staff fields blank and you get a pure revenue number. Fill them in and the calculator adds them, but it never merges them into the revenue line. You always see the split.

Use loaded hourly cost, not take-home pay. Salary plus tax plus overhead, divided by working hours. For most small teams that lands somewhere north of what the payslip says.

Effective uptime uses a different denominator, deliberately

Revenue per minute may use business hours. Effective uptime never does. It always divides your total annual downtime by calendar minutes, because that is what an SLA measures and what your hosting contract means.

The two numbers answer different questions. Keeping the denominators separate is the only way both stay honest.

Detection is eating most of the loss

If nobody notices for fifteen minutes or more, a large slice of your annual cost is spent before anyone even starts fixing anything. That slice is the cheapest one to remove.

You do not need a monitoring platform or a subscription to fix it. An uptime check hitting a real endpoint every sixty seconds, alerting to a channel someone actually reads, closes most of the gap. Check the thing that matters, not just whether the server answers. A homepage returning 200 while checkout is broken is worse than no check at all.

Effective uptime is under 99.5%

Around forty-four hours of downtime a year puts you below 99.5%. Most B2B contracts quietly assume better than that.

At this level the cause is rarely bad luck. Usually there is one component with no redundancy behind it, and every outage traces back to the same place. Finding it is an afternoon of reading logs and drawing the dependency chain, not a rebuild.

Six or more incidents a year

That is roughly one every eight weeks. At that frequency the pattern matters more than any single failure.

In practice it is usually resource limits creeping up on you: memory, disk, connection pools, certificate renewals nobody automated. Adding monitoring on top of that tells you faster, but it does not stop it happening. Find the pattern first.

Cleanup takes longer than the outage

If you spend more hours reconciling afterwards than you spent down, the restore path is the problem. Either there is no tested rollback, or there is one nobody has rehearsed.

This is the cheapest item on the list to fix and the one most often left alone. A rollback you have actually practised turns a two-day cleanup into twenty minutes.