What It Costs You When Your Site Goes Down

The usual method is revenue divided by hours, times the length of the outage. It is quick, it survives a meeting, and it captures the smallest part of what an outage costs you.

It assumes the sale is lost rather than delayed, which for some businesses is simply wrong. It also counts only the hours the systems were off, when the mess reliably outlasts the outage by days.

Idle staff first. Everybody who cannot do their job is being paid to wait, and that group is nearly always larger than the group who use the broken system directly.

Then the workaround. People do not sit still. They move to paper, to spreadsheets, to their own email, to phoning the customer. Those workarounds keep you trading, and every one of them creates data that somebody has to type back in later.

Then the response itself. Engineers come off planned work. Support contracts get invoked, sometimes at a premium. Senior people spend the day on a call instead of doing their jobs. Some of that is already paid for. None of it is free.

The backlog is the biggest part. Work that did not happen still has to happen, on top of the normal load. That means overtime, late delivery, or both.

Then putting the records straight. Orders taken on paper get entered twice or not at all. Stock counts drift. Invoices go out late or wrong, and correcting them eats finance time for weeks. Mistakes made during a workaround surface slowly and cost more to fix than they would have cost to prevent.

Then the obligations. Your support line takes the calls. Account managers spend the week explaining rather than selling. Where a contract carries a commitment, an outage may trigger credits or a formal review. Where a regulator is involved, there may be a notice to file and a file to build.

Trust falls slowly and shows up late. Customers rarely leave over one outage. They leave after the third, and by then they give a different reason.

Inside the business, repeated outages wear out the people who fix them. The engineers who worked through the night are the ones you most want to keep and the ones who find it easiest to leave. What it costs to hire after a bad year is a downtime cost, even though nobody files it as one.

And every incident eats time that was meant for improvement. The project that would have prevented the next outage slips because of the response to this one. That is how a team becomes permanently reactive.

Do it with your finance team, and do it per function rather than for the company as a whole. Taking orders, getting them out, delivering the service and billing for it all fail differently and at different speeds.

For each one, estimate how many people stop, what an hour of their time costs you, how much of the work is delayed rather than lost, how much rework each hour of outage creates, and what any contract or regulation adds on top. Then ask how it behaves over time, because it is almost never a straight line. Plenty of businesses absorb an hour with no trace and are in serious trouble at a day.

The output is a range with the assumptions written beside it. A range survives being questioned. A precise figure starts an argument about the third digit and loses the point.

The figure exists to make choices comparable. A second server, faster recovery and better monitoring all cost money, and the only sane way to size that spend is against what an outage costs you and how likely one is.

It also turns recovery targets from a technical preference into a business decision. When a department sees the cost of a day of its own downtime next to the price of being back in four hours instead of twenty four, the conversation stops being an argument with IT and becomes a budget one. That is where it belongs.