keymodels
Process or machine downtime level
How can process or machine downtime level improve people, teams, or organisational effectiveness?
Contents
Helps managers answer: To what extent are we operating our processes or machines effectively?
Process or machine downtime measures periods when a required asset or workflow is unavailable for productive use. It helps an organisation understand lost capacity, service interruption and reliability. The measure should distinguish planned maintenance from unplanned failure and should never reward deferring work needed for safety or long-term asset health.
When to use it
- Answer the performance question: “When required, how reliably are our machines or processes available?”
- Assess the KPI within operational processes and the supply chain.
- Locate recurring failure, maintenance, hand-off or recovery losses.
- Plan definitions, collection, reporting and response thresholds.
- Pair downtime with safety, quality, throughput, maintenance health and customer outcomes.
Origins
Downtime measurement grew from maintenance engineering, reliability analysis and production control. Manufacturing made machine unavailability visible, while service operations later applied the same logic to systems, equipment and end-to-end processes. There is no single inventor of the indicator; it is one component of broader availability and reliability practice.
What it is
Perspective: Operational processes and supply chain perspective.
Key performance question: When required, how reliably are our processes or machines available?
Downtime is time inside a defined required-service window when an asset or process cannot perform its intended function. The denominator matters. An asset undergoing maintenance when no production is scheduled may not be unavailable to the business, whereas a short failure during critical demand may be severe.
Define planned downtime, unplanned downtime, degraded operation, changeovers, waiting, upstream blockage and data outages separately. A call centre may track service-system interruption; a hospital may track diagnostic-equipment availability; a factory may track a machine. The same headline percentage can represent very different operational and customer consequences.
How to use it
Measurement
Set the asset or process boundary, required operating window, start and end events, minimum functional state and treatment of partial capacity. Decide whether simultaneous failures are reported separately and how planned maintenance is classified.
Data collection method
Capture events automatically from machines, workflow systems or monitoring tools where possible. Manual logs may be required for causes and recovery actions. Reconcile timestamps, reason codes and work orders; an automated signal can show that equipment stopped without explaining why.
Formula
Downtime level can be expressed as a ratio:
Report absolute duration and event count beside the percentage. A ratio alone can hide many brief interruptions or one long outage.
Frequency
Collect continuously where operational response is time-critical and alert when a defined threshold is crossed. Monthly or quarterly summaries may support governance, but they should not delay incident response. Review trends by asset, cause, shift, product and service impact.
Source of the data
Sources include machine controls, manufacturing or workflow systems, incident records, maintenance work orders and structured manual logs. Establish one clock, event taxonomy and data owner.
Cost/effort in collecting the data
Effort is moderate when reliable events already exist and higher when sensors, integration or manual recording are needed. Automation reduces routine entry but introduces configuration, validation and maintenance costs. Start with evidence that can drive a real decision.
Target setting/benchmarks
Zero unplanned downtime may be a useful aspiration, but zero total downtime is usually neither realistic nor desirable. Preventive maintenance, inspection, upgrades and safe shutdowns protect future availability. Set targets from service requirements, risk, asset criticality and economic trade-offs rather than a generic benchmark.
Example
A hospital radiography department has two CT scanners. It wants at least one available 24 hours a day and both available during routine business hours, from 9am to 5pm = 8 hours.
It defines ordinary downtime as any routine-hours period when one scanner is unavailable and critical downtime as any period when both are unavailable. Over a 24-hour time frame:
CT scanner 1 is unavailable from 1pm to 3pm because of a fault and from 7pm to 10pm for maintenance.
CT scanner 2 is unavailable from 7pm to 8pm because of a fault.
Under the inherited routine-hours definition, downtime level for CT scanner 2 = 0%. That result does not mean the evening failure was irrelevant. Report clinical or service impact and critical overlap separately, and let qualified healthcare and engineering teams define safe availability requirements.
Top practical tip
Link every downtime event to cause, service impact, recovery time and cost—including idle labour, missed output and customer consequences. Prioritise by criticality, not duration alone.
Top pitfall
A zero target can encourage hidden failures or deferred maintenance. Poorly defined service windows and reason codes make the ratio easy to improve without improving reliability.