The short answer
To calculate downtime, log every event with its start and end time, add up the durations over a month or a year and track how often events happen, using MTBF and MTTR to follow reliability and repair speed. To calculate its cost, add five parts for each event: lost revenue (hourly revenue × hours down), lost productivity (affected employees × average hourly wage × hours down), recovery costs, customer impact (lost sales plus compensation) and opportunity costs such as delayed projects.
What downtime is and what causes it
- Downtime
- A period during which systems, applications or services are unavailable or not working as they should.
Downtime is a quiet productivity killer: it can go unnoticed until it starts to hurt the business badly, from revenue to customer trust. Its opposite, uptime, is the share of time a system or device is operational, so the same method applies whether the thing that stops is a web service, a back-end platform or connected equipment.
- System errors: failures of the systems themselves
- Software bugs: flaws in code that make an application crash or behave unpredictably
- Cyberattacks: DDoS attacks and security breaches that make systems inaccessible
- Human error: updates, configuration changes or maintenance that accidentally cause an outage
- Natural disasters: earthquakes, floods and fires that physically damage infrastructure
How to calculate downtime
Understanding the impact of downtime, and preventing it, starts with knowing how much of it you have.
- Identify downtime eventsLog every event with monitoring tools and record its start and end time, so you know exactly when systems are up and when they are down.
- Measure durationCalculate the duration of each event and add them up over a month or a year.
- Assess frequencyCount how often downtime happens in a period. Frequent short outages can disrupt operations and customers as much as rare long ones.
- Assess impactFor each event, estimate the revenue lost, how many employees could not work and how many customers were affected or lost.
- Track metricsFollow reliability and repair efficiency with KPIs such as MTBF and MTTR.
- MTBF and MTTR
- Mean Time Between Failures measures how reliable a system is; Mean Time to Repair measures how quickly it is restored after a failure.
What downtime costs: direct and indirect
| Cost | Type | What it covers |
|---|---|---|
| Revenue loss | Direct | Sales or output that cannot be processed while systems are down; even a short outage at a peak time can be expensive |
| Productivity loss | Direct | Employees who cannot do their work, delaying project timelines |
| Customer dissatisfaction | Direct | Lost trust and customers who stop buying |
| Recovery costs | Direct | Overtime for the team that restores systems, outside consultants, new infrastructure to avoid a repeat |
| Reputational damage | Indirect | Frequent or long outages tarnish the company's reputation, and rebuilding trust takes time and resources |
| Opportunity costs | Indirect | New features, markets or projects missed or delayed because systems were unavailable |
| Regulatory fines | Indirect | In regulated industries such as finance and healthcare, downtime can mean non-compliance, fines and legal consequences |
Downtime also carries risks that are harder to price: data loss during an outage, higher customer support costs, and competitors gaining ground while your service is unavailable.
How to calculate the cost of downtime
- Hourly revenueHourly revenue = annual revenue ÷ total working hours in the year. This is the yardstick for the immediate monetary loss.
- Productivity lossProductivity loss = number of affected employees × average hourly wage × downtime duration in hours.
- Recovery costsEverything spent to resolve the event: overtime, consultants, temporary fixes and purchases made to prevent a repeat.
- Customer impactSales lost because the system was offline, plus any compensation paid to affected customers.
- Opportunity costsRevenue from projects, sales or releases that were delayed by the outage.
- Total costTotal = hourly revenue × hours down + productivity loss + recovery costs + customer impact + opportunity costs.
Laying out the calculation
Put each component in one row with the inputs it needs and where those inputs come from. Working hours for the hourly revenue figure are the hours the business actually operates in a year, for example a working week multiplied by the working weeks in the year.
| Component | Inputs | Where the data comes from |
|---|---|---|
| Revenue loss | Hourly revenue and hours down | Annual revenue, operating hours and the event log |
| Productivity loss | Affected employees, average hourly wage and hours down | Staffing records and the event log |
| Recovery costs | Overtime, consultants, temporary fixes and preventive purchases | Incident records and invoices |
| Customer impact | Sales lost during the outage and compensation paid | Sales and support data |
| Opportunity costs | Revenue from delayed projects, sales or releases | Project and sales plans |
| Total | Sum of the five components | The rows above |
Tools that help calculate downtime costs
- Monitoring tools record downtime events and the statistics around them, which gives the start and end times the calculation needs.
- Incident management systems log and track each event, so the cost data for every outage is in one place.
- Business intelligence and analysis tools combine many events and plot cost trends over time.
How to reduce downtime
Reliability is not just the absence of failures. It is predictability, stability and the guarantee that a product or service will be available when it is needed. Quantifying downtime is what makes the case for investing in it.
Practices that keep systems available
- Continuous monitoring, so problems are detected and corrected early
- Root cause analysis of every outage, not only a fix of the symptom
- Regular backups, so systems can be restored after a disaster
- High availability through data replication and automatic scaling, so the system keeps working when one component fails
- Automation of build, test and deployment to reduce human error
- Infrastructure defined as code, with version control, review and rollback
- A disaster recovery plan that is tested before a real crisis
- Authentication, authorisation and encryption to guard against attacks
Using the downtime cost to justify investment
A cost of downtime turns reliability from a technical wish into a business decision. Compare it with the cost of a reliability improvement through return on investment: net profit from the investment divided by its total cost. More uptime usually means more consistent revenue, fewer repairs and replacements, less lost productivity and more satisfied customers.
Key takeaways
- Measure both the direct and the indirect costs of each event
- Account for customer satisfaction and reputation, even if they are hard to quantify
- Use realistic numbers for your industry and business size
- State the timeframe, because the return changes with it
- Assess how downtime affects each part of the business, not only the system that failed
From measuring downtime to predicting it
Everything above measures downtime after it has happened. The next step is to see it coming. Many equipment failures announce themselves before they stop anything: a bearing starts to vibrate differently, a motor draws more current, a pump runs hotter. Condition monitoring puts sensors on those signals – vibration, temperature, current, pressure – and records them continuously, so the state of the equipment is known between failures and not only after them. Vibration diagnostics on rotating machinery is a typical starting point.
Anomaly detection then compares live signals with what normal operation looks like and flags departures from it. It can run at the edge, on the device or a nearby gateway, where it reacts without a round trip to a server and keeps working when the connection drops. It can run in the cloud, where it sees a whole fleet and can afford heavier models. Many systems split the work: the edge filters and flags, the cloud learns and compares across assets. Where each part runs is an AI for IoT architecture decision, set by latency, connectivity and the processing power on the device.
What data you need first
A predictive model is only as good as its baseline, and the method in this article already produces it. The downtime log, with start and end times, causes and affected assets, marks the moments a model should have warned about. Sensor history from before those events becomes training data, and later events become validation: did the model flag them early enough to act? The cost inputs decide what matters, because a model that predicts cheap, harmless failures is worth less than one that catches the expensive ones.
In practice an industrial IoT system grows in this order: logging first, then monitoring, then prediction, with each stage built on the data the previous one collected. That is the step from connected equipment to an intelligent connected product – one that senses its own condition and asks for attention before it stops.
Was this useful?
Where this shows up in our work
SolutionIndustrial IoT & IntelligenceIf downtime of connected equipment is the cost you are measuring, see how monitoring systems log events and surface problems before they stop production.Apply this to your product