What Does System Downtime Cost You? A Practical Way to Calculate It

Discussions about investing in IT infrastructure usually revolve around cost alone, because the other side of the equation is never calculated. Once system downtime has a number, the discussion shifts from "should we spend?" to "how much is it worth spending?", and that is a question management can answer in minutes.

Why you need a number

Without a number, every request to improve availability looks like an extra cost. With a number, it becomes a simple comparison: the cost of prevention against the cost of the incident multiplied by its likelihood. The number does not need to be accurate to the riyal. It only needs to be in the right order of magnitude to change the decision.

The four components of the hourly cost

1. Lost productivity

The simplest component and the easiest to calculate:

Affected employees × average fully loaded hourly cost × share of their work actually stopped

Watch the share of work stopped: it is rarely 100%. Some employees move on to other tasks. But also keep in mind that postponed work rarely disappears. It comes back later as overtime or as delayed delivery.

2. Lost revenue

This applies when the system that is down sits directly in the sales path (an online store, point of sale, a booking platform). Calculate it from the average hourly revenue of that channel, and take timing into account: an hour of downtime at peak demand is not the same as an hour at a quiet time.

Subtract what will actually be recovered, since some sales are postponed rather than lost. And add what never comes back: a customer who went to a competitor and did not return.

3. Recovery cost

The IT team's hours during and after the fix, any emergency outside support (which always costs more than support contracted in advance), re-entering lost data, and the hours spent on verification and reconciliation.

4. Indirect costs

The hardest to calculate and the largest in long-term impact: reputational damage, penalty clauses in customer contracts, regulatory disclosure requirements if the incident involves data, and management attention pulled away from its priorities for days.

Do not try to be precise here. Put in a conservative estimate and state that it is an estimate. Having it in the calculation is better than leaving it out, because leaving it out implicitly says it is zero.

A worked example

The figures below are hypothetical and for illustration only; replace them with your organization's numbers. Assume an organization where 60 employees are affected when the core system goes down:

Component	How it is calculated	Result per hour
Productivity	60 employees × SAR 150/hour × 70% stopped	SAR 6,300
Lost revenue	Average hourly revenue of the affected channel	SAR 4,000
Recovery	Team hours + emergency support, spread over the incident duration	SAR 1,200
Indirect	Conservative estimate	SAR 1,500
Total		About SAR 13,000 per hour

With this number, the difference between an agreement that allows seven hours of outage a month and one that allows forty minutes becomes a difference you can measure in riyals, not an abstract technical debate.

From the number to the decision

Once you have the hourly cost, there are three practical steps:

• Rank your systems by the cost of their downtime, not by their technical complexity
• Match each system to a level of coverage that fits its cost; do not buy the top tier for everything
• Compare the cost of raising the coverage level with the expected yearly savings in downtime hours

In each periodic review, put what the achieved availability means in riyals next to the percentage. This turns the operations report from a technical document read by one team into management information that decisions are built on.

Summary

You do not need a complex financial model. You need one rough number, agreed between management and IT, reviewed every year. Having that number alone changes how infrastructure is discussed more than any presentation.