How to calculate the cost of a service outage

When a technology infrastructure stops working, the first indicator that usually appears is time. How many minutes the system has been down, how long it will take to recover, how much margin is left before the incident affects another area. From a business perspective, however, time on its own explains very little. A twenty-minute interruption can be practically irrelevant for one organisation and cause significant losses for another. Even within the same company, an hour of unavailability can have completely different consequences depending on the system affected, when it happens or the processes that depend on it.

That is why calculating the cost of a service outage means looking beyond the infrastructure. It is not simply about putting a price on every hour of downtime, but about understanding what happens in the organisation when part of its technology ecosystem becomes unavailable.

This perspective is especially important in industrial companies, multi-site companies and organisations that operate critical infrastructure. In them, technology and operations are so closely linked that a seemingly technical incident can quickly spread to production, logistics, customer service, administration or security. The relevant question is then no longer how much it costs to repair a server, an application or a network. The question becomes how much it really costs for the business not to be able to use them.

The cost of an outage starts long before the supplier's invoice

There is a simple way to understand the problem. Imagine a company whose management system becomes unavailable for two hours. The visible cost may include the technical team's work, some overtime and perhaps a specialist's travel. These are relatively easy figures to identify because they end up appearing on an invoice or a timesheet.

The real economic impact is usually much wider.

During those two hours there may be employees waiting, orders not being processed, logistics operations being delayed, machines working below capacity or departments falling back on manual procedures. After the service is restored, pending information will have to be entered, data consistency checked, errors made during the contingency fixed and the backlog absorbed.

Technically, the incident ends when the system is working again. Economically, it can go on for hours or even days.

This difference between technical recovery and operational recovery is fundamental to valuing downtime correctly. An organisation may restore an application at 12:00 and not get back to its usual pace until 15:00. If it only counts the period during which the application was down, it will be underestimating the impact of the interruption.

A simple formula to start measuring downtime

There is no universal formula that captures every cost of an interruption, but it is possible to build a model practical enough for decision-making. As a starting point, the cost of a service outage can be expressed as follows:

Total cost of the interruption = operational loss + lost productivity + recovery costs + commercial impact + knock-on costs + reputational and regulatory impact.

The result does not always have to be an exact figure down to the last euro. In technology management it is usually far more useful to have a consistent estimate, based on uniform criteria, than to chase impossible precision.

Suppose, for example, that a given operation generates or supports €120,000 of economic activity during an eight-hour working day. A first approximation would put the value of that activity at €15,000 per hour. If an interruption completely blocks the operation for 45 minutes, we would have a theoretical direct exposure of €11,250.

But that calculation would still be incomplete.

We would need to determine what percentage of the activity is really paralysed, which processes can continue, how many people are left unproductive, what additional costs appear during recovery and how much of the work can be recovered later. We would also need to include less immediate consequences: breaches of service agreements, delivery delays, lost sales or impact on customers.

The goal is not to complicate the formula, but to make it reflect how the company really works.

Not every minute has the same value

One of the most common mistakes when analysing availability is to assume that every hour of downtime costs the same. That is rarely the case.

An interruption to an ordering system in the early hours of a Sunday may have limited impact. The same interruption at the peak of commercial activity can block a significant share of revenue. In an industrial plant, losing connectivity during a scheduled stoppage does not have the same consequences as losing it with a line running at full capacity.

That is why the calculation should introduce the concept of time criticality. The cost per hour can vary by shift, sales campaign, production schedule, administrative closings or any other especially sensitive moment for the organisation.

This idea makes it possible to move from a generic calculation to a far more useful model for business continuity. We no longer ask only how much it costs for a system to stop, but when it is most costly for it to stop.

The difference matters because it helps prioritise investment. An infrastructure may not need the same level of redundancy twenty-four hours a day, but it may need especially demanding guarantees during certain time windows. In other cases, as with continuous industrial operations or certain essential services, criticality can remain practically constant.

When IT stops, the problem rarely stays in IT

In digitalised organisations, a service outage tends to spread.

A connectivity problem can cut off access to corporate applications. An unavailable database can affect several tools at the same time. An incident in an identity system can stop hundreds of users from accessing services that are technically still working. And in industrial environments, the interdependence between information technology and operational technology adds another dimension to the problem.

IT/OT convergence has brought major improvements in visibility, control and efficiency, but it has also created more complex dependency chains. Corporate infrastructure can feed systems related to planning, maintenance, quality, traceability or production. When one of the components connecting those worlds fails, the impact can quickly cut across different levels of the organisation.

This is where an especially useful concept for calculating the real cost comes in: the blast radius.

It is not enough to identify which element has failed. You need to determine how many processes depend on it, directly or indirectly. An application used by twenty people can be more critical than one used by five hundred if the first controls a process with no operational alternative.

This view also avoids a common mistake when setting technology priorities: confusing number of users with business criticality.

Lost productivity is harder to calculate than it seems

The first approach is usually to multiply the number of affected workers by their hourly cost and by the duration of the incident. It is a valid reference, but it needs some nuances.

Not every employee becomes completely unproductive. Some can carry out alternative tasks. Others work at a slower pace. Certain operations can continue using manual procedures. That is why it is worth introducing an estimated percentage of productivity loss.

If 80 people have an average labour cost of €35 per hour and a two-hour incident reduces their productivity by 60%, the estimated impact would be:

80 × €35 × 2 hours × 60% = €3,360.

Even here, however, something is still missing. Work not done during the outage does not always disappear. Often it piles up.

When the service comes back, the organisation has to absorb that extra load. There may be overtime, bottlenecks, errors caused by rushing or delays in other processes. The cost of the interruption thus extends into the period after recovery.

Measuring this second phase is especially interesting because it can reveal that certain seemingly small incidents generate a disproportionate operational bill.

In industry, a stoppage can have physical effects

In an office environment, a technology outage usually translates mainly into unproductive time. In an industrial plant the consequences can be different.

An interruption can affect the production rate, produce out-of-spec product, waste raw materials or require restarts and checks before normal capacity is recovered. Some processes also need controlled shutdown and start-up sequences, so fifteen minutes of technology unavailability can turn into a much longer operational period.

The calculation must then include elements specific to the production process: units not manufactured, margin per unit, wasted material, energy consumed during the stoppage, staff hours, additional quality checks and the time needed to stabilise production again.

This explains why technology availability is particularly relevant in industrial environments. IT/OT infrastructure, networks, systems, connectivity and software do not work in isolation: they are part of an operational chain that can ultimately materialise in products, deliveries and commitments to customers.

There is also a commercial cost

Not all losses appear inside the company.

An outage can prevent orders from being placed, a platform from being accessed, requests from being handled or a contractually committed service from being delivered. Depending on the business model, this can mean lost sales, penalties for SLA breaches, cancellations or compensation.

It is also worth distinguishing between delayed sales and lost sales. If a customer cannot complete a transaction at ten in the morning but completes it two hours later, there is an impact, even though the revenue eventually comes in. If they decide to go to another supplier, the nature of the cost changes.

A real case we experienced very closely at Motum recently: in an industrial environment close to us, an interruption made it impossible to meet the production planned for that day. The commercial impact, however, was not limited to that lost production. Faced with uncertainty about when the service would be restored, the customer also decided to cancel the production scheduled for the following days until it had guarantees that operations were stable again. A one-off outage thus ended up causing a commercial loss far greater than the one corresponding to the actual hours of unavailability.

In B2B companies another, less immediate factor appears: trust. Customers can accept that an incident happens. What is much harder to manage is repetition, lack of information or the feeling that the supplier is not in control of its infrastructure.

Reputational cost is hard to translate into euros, but that does not mean it should be ignored. It can be approximated by looking at subsequent cancellations, complaints, churn, lower business volume from affected customers or more resources devoted to rebuilding the commercial relationship.

Cybersecurity adds a different dimension to downtime

Not all interruptions are accidental. Some are the result of a security incident.

In that scenario, counting only the hours without service is clearly not enough. An organisation can get operations running again while it is still investigating the scope of the attack, restoring equipment, reviewing credentials, analysing logs or verifying the integrity of its systems.

There may also be regulatory obligations, specialised incident response services, legal advice, forensic analysis and costs related to communication or third-party management.

This makes cybersecurity a matter closely tied to operational continuity. Protecting an organisation is not only about preventing unauthorised access; it also means increasing its ability to detect, contain and recover from an incident without it compromising the running of the business for a long time.

In IT/OT environments this becomes even more relevant, because a single organisation can combine corporate systems, industrial networks, devices, servers, applications and equipment with very different life cycles and levels of exposure.

From the cost of an outage to the cost of unavailability

Analysing a single incident provides useful information. Analysing all the interruptions over a period reveals something far more valuable.

Suppose a system suffers six interruptions a year, each relatively short. None of them seems to justify a significant investment on its own. However, once lost productivity, technical intervention, delays and recovery costs are added up, the annual impact can completely change the picture.

We can express it simply:

Annual cost of unavailability = sum of the cost of all interruptions + recurring costs of managing them.

This indicator makes it possible to compare the cost of keeping the current situation with the cost of improving it.

This is where calculating downtime stops being a financial curiosity and becomes a decision-making tool. If an infrastructure causes estimated losses of €90,000 a year due to interruptions, and there is an improvement in architecture, monitoring, redundancy or management that could significantly reduce that risk, the conversation about technology investment takes on a different context.

We are not comparing the cost of a new solution with zero. We are comparing it with the economic cost of carrying on as before.

MTTD, MTTR, RTO and RPO: technical metrics also talk about money

To reduce the economic impact of outages, it is useful to link financial metrics with operational indicators.

MTTD (Mean Time to Detect) measures how much time passes before an incident is detected. MTTR (Mean Time to Repair or Recover) reflects how long the organisation takes to resolve it or restore the service. The longer both times are, the longer the impact will normally last.

RTO (Recovery Time Objective) sets how long a service can remain interrupted before exceeding the limit acceptable to the business. RPO (Recovery Point Objective) determines how much information, measured in time, could be lost in a recovery scenario.

Things get interesting when these indicators stop being defined by technology alone.

If we know that an hour of downtime of a given service represents an economic exposure of €25,000, setting an RTO of four hours is no longer a purely technical decision. We are potentially accepting an impact scenario of up to €100,000, to which other costs would have to be added.

Translating availability, recovery and data loss into economic terms makes it easier for management, operations and technology to make decisions using a common framework.

Prevention also has to make economic sense

Knowing the cost of an outage does not mean that any investment to prevent it is justified.

Absolute availability is an extraordinarily expensive goal and, in many scenarios, an unnecessary one. Adding redundancy, replication, backup systems, alternative communications, advanced monitoring or specialised resources increases resilience, but also cost and complexity.

The right decision is to find a balance between cost of prevention and cost of exposure.

A service whose downtime costs €500 per hour probably does not need the same architecture as one whose interruption costs €50,000. In the same way, an auxiliary application should not necessarily receive the same level of protection as a system essential to keeping a plant running.

This classification makes it possible to allocate resources where they create the most value and avoids two equally problematic extremes: under-protected infrastructure and architectures oversized for the real risk.

Monitoring changes the economics of an incident

One of the most effective ways to reduce the cost of downtime is simply to reduce its duration.

It seems obvious, but there is a considerable difference between spotting an anomaly before it has affected the user and receiving the first alert when operations have already stopped. There is also a difference between starting the diagnosis immediately and spending the first half hour working out which supplier needs to step in.

Continuous monitoring, observability, escalation procedures and a clear allocation of responsibilities can reduce both detection and recovery times.

Managed service models offer an interesting perspective here. Compared with purely reactive management —waiting for something to fail before acting—, a continuous approach seeks to know the state of the infrastructure, detect deviations and manage incidents within previously defined procedures.

Motum Technologies designs its Smart Managed Services precisely around the provisioning, operation, monitoring and continuity of critical environments, integrating IT/OT infrastructure, connectivity, support and cybersecurity.

The economic difference does not lie only in avoiding incidents. It also lies in detecting them earlier, limiting their impact and restoring the service faster.

Software is also part of availability

When we talk about service outages we tend to think of servers, networks or communications. However, a growing share of business continuity depends on software and on the integrations between systems.

An application can be technically available and still be unable to complete a process because an API is not responding, an integration has failed or a required piece of data is not arriving from another system. From the user's point of view, the result is practically the same: the service does not work.

That is why a mature continuity strategy must cover the whole chain. Infrastructure, connectivity, software, databases, integrations, access and cybersecurity are all part of the same operational experience.

The ability to develop integrations and applications tailored to the business can also help remove certain weak points, automate contingency mechanisms or provide greater visibility into critical processes. In this sense, availability does not depend only on keeping machines switched on. It depends on the whole process being able to keep working.

The real goal: knowing what to protect first

Calculating the cost of a service outage should not end in a spreadsheet. Its usefulness lies in what it lets you decide afterwards.

When a company knows which systems support its critical processes, how much their unavailability costs and how long it can afford to operate without them, it can set priorities much more precisely. It can decide where it needs redundancy, what it should monitor continuously, which systems need better backup and recovery mechanisms, where connectivity should be reviewed and which services need specialised support.

It can also negotiate SLAs that better match its real needs and evaluate suppliers using business-related criteria, not just technical specifications.

This view is especially relevant in complex organisations. Today's technology infrastructure is made up of interdependent layers, in many cases managed by different suppliers. When an incident occurs, the ability to coordinate those layers can be as important as the technology used.

Motum Technologies' approach starts precisely from that integrated view: managing and optimising critical technology by combining IT/OT infrastructure, connectivity and networks, support, monitoring, cybersecurity and software development from a perspective focused on operational continuity.

Because the best way to calculate a service outage is not to wait for it to happen.

It is to know in advance how much it could cost, how long the business can withstand it and which capabilities must be ready to stop a technical incident from turning into a business problem.