Key takeaways
Short answer: Uptime and downtime are two sides of the same clock. Uptime is the time equipment is running and producing; downtime is the time it is stopped when it should have been running. Add them up and you fill the scheduled time, so an uptime percentage and a downtime percentage carry the same headline information. The difference is usefulness: uptime is a score, while downtime — especially broken down by planned versus unplanned and by reason — is a to-do list. The detail that drives improvement lives on the downtime side. For the factor this drives, see availability vs reliability.
Uptime is the portion of scheduled production time that equipment is actually running and producing. It is usually expressed as a percentage of the time the asset was meant to be available — a machine up for 90% of its scheduled hours has 90% uptime. Uptime is an appealing headline number: it is simple, positive, and easy to communicate to management. But that simplicity is also its weakness. Uptime is an aggregate score that tells you the result without telling you anything about the cause. A 90% uptime figure says nothing about whether the missing 10% was one planned changeover or fifty unplanned breakdowns — and those are completely different situations demanding completely different responses.
Downtime is the portion of scheduled time that equipment is stopped when it was meant to be running. It is the complement of uptime, but it is far richer, because downtime can — and should — be classified. The first cut is planned versus unplanned: planned downtime (scheduled maintenance, planned changeovers) is expected and managed, while unplanned downtime (breakdowns, faults, material shortages) is the expensive, disruptive kind. Beneath that, each downtime event can carry a reason code: what stopped, why, for how long. This is what makes downtime the actionable view — it does not just tell you the line was stopped, it tells you what to fix and which losses are biggest.
Mathematically uptime and downtime are just two ways of reporting the same gap — one counts the running time, the other the stopped time, and they sum to the scheduled total. So why prefer downtime? Because improvement needs causes, not just a score, and causes live on the downtime side. An uptime percentage is a result you report; a classified downtime breakdown is a problem list you act on. Watching uptime alone tends to produce comfort or alarm without direction. Watching downtime by reason produces a ranked set of specific things to attack. The same information, framed for action rather than for the scoreboard.
Two machines both post 85% uptime over a week — identical on the scoreboard. Now look at the downtime. Machine A's 15% is a single, planned eight-hour maintenance window: expected, managed, harmless to the plan. Machine B's 15% is forty short unplanned stops — jams, faults, and minor failures scattered across every shift, each a scramble. Same uptime, utterly different reality: Machine A is healthy, Machine B is bleeding through chronic micro-stops that signal a developing problem and devour operator attention. The uptime number hid the difference completely; the downtime breakdown exposed it and pointed straight at Machine B's recurring jams as the thing to fix. That is why you manage the downtime, not the uptime.
The value of downtime comes from classification and ranking. Capture every stop with a reason code, split planned from unplanned, and then sort by total impact — usually a Pareto, where a few reasons account for most of the lost time. That ranking is your improvement queue: attack the biggest unplanned downtime cause first, confirm the loss shrinks, then move to the next. Two cautions: make the reason codes meaningful and consistent (vague or inconsistent codes produce untrustworthy data), and watch frequency as well as duration, because many tiny stops can quietly out-cost a few big ones while never feeling like a crisis. Managed this way, downtime data becomes the engine of availability improvement.
Uptime maps closely to the availability factor of OEE — though OEE refines it by separating planned from unplanned time and by capturing the small stops and slow running that a crude uptime figure misses. The real power is in the downtime breakdown: OEE attributes lost time to specific causes within the six big losses, turning availability from a score into a diagnosis. Frequent short stops, which barely dent uptime, also drag down the performance factor — so an unplanned-downtime problem often shows up as a double OEE hit. Classifying downtime is what connects a sagging OEE to the specific fix.
Fabrico is built around exactly this: it captures every stop with its duration and reason, separates planned from unplanned, and ranks downtime causes by their real cost in lost OEE. Instead of an uptime number that reassures without directing, you get a prioritized list of what is actually stopping the line and what it costs — the difference between knowing you lost 15% and knowing precisely which recurring faults to fix first. Book a demo to turn your downtime into a ranked improvement queue.
Uptime is the time equipment is running and producing; downtime is the time it is stopped when it was meant to run. They are complementary and sum to the scheduled time, but downtime carries the actionable detail — the causes — while uptime is just a score.
Uptime maps closely to the availability factor of OEE, but OEE refines it by separating planned from unplanned downtime and capturing small stops and slow running that a simple uptime figure can miss. Uptime is a simpler, cruder version of availability.
Because improvement needs causes, and causes live on the downtime side. An uptime percentage is a result; a classified downtime breakdown — by planned versus unplanned and by reason — is a ranked list of specific problems to fix.
Planned downtime is expected and managed, such as scheduled maintenance or planned changeovers. Unplanned downtime is unexpected and disruptive, such as breakdowns, faults, or material shortages. Unplanned downtime is usually the costly kind to attack first.
Downtime drives the availability factor, and OEE attributes it to specific causes within the six big losses. Frequent short stops also lower the performance factor, so unplanned downtime often hits OEE twice. Classifying downtime connects a low OEE to the fix.
Zaloguj
Blog
