A failure is the loss of an asset's ability to perform its required function, either partially or completely, while a breakdown is the operational consequence of a failure that is severe enough to stop the asset or halt production. Every breakdown starts from a failure, but not every failure ends in a breakdown — a bearing running hot and loud has failed functionally even while the machine keeps producing parts. Maintenance teams that log only breakdowns miss the failures caught early, degraded slowly, or fixed before a stoppage, which quietly understates how often assets are actually degrading.
Key Takeaways
A failure is the loss of a component, system, or asset's ability to perform its required function against its intended performance standard, whether that loss is partial or complete. A breakdown is the operational consequence of a failure that is severe enough to stop the asset, halt production, or force emergency intervention. The distinction matters because a functional failure can exist for days or weeks — a pump running with excess vibration, a conveyor motor drawing higher amperage than normal — before it ever becomes a breakdown, if it becomes one at all.
Maintenance teams that use the words interchangeably end up with a data set that only shows the tip of the iceberg. Reliability engineering, root cause analysis, and MTBF/MTTR calculations all depend on capturing a failure at the point it begins, not just at the point the line stops.
| Attribute | Failure | Breakdown |
|---|---|---|
| Definition | Loss of required function, partial or complete | Operational stoppage caused by a severe failure |
| Asset still running? | Often yes, in a degraded state | No — production is halted |
| Detection point | Abnormal reading, sound, or performance drop | Line stop, alarm, or emergency call |
| Work order type | Scheduled corrective, if not resolved in time | Emergency corrective, routed immediately |
| What it feeds | Failure mode trends, RCA timelines, MTBF | Downtime cost, MTTR, capital planning |
Cryotos gives maintenance teams a structured way to separate these two events at the point of capture, so failure data and breakdown data can each be trusted, tracked, and analyzed independently and together.
The distinction changes what a maintenance team actually measures. A team that logs only breakdowns sees just the failures severe enough to force a stoppage — every failure that was caught early, degraded gradually, or got fixed before the line stopped never enters the record. Over a year, that gap can represent hundreds of events that a breakdown-only log simply never sees, because nothing about them ever forced the line to stop.
This is why two facilities can report the same breakdown count and still be in very different reliability positions. One facility might be catching ninety failures for every ten breakdowns, while another catches only fifteen failures for the same ten breakdowns — meaning most of its failures are going undetected until they escalate. A breakdown-only report makes both facilities look identical, even though one has a functioning early-warning process and the other does not.
According to ISO 55000 principles for asset management, organizations that manage assets on a full lifecycle basis — not just on stoppage events — get a more accurate picture of degradation and risk. Maintenance teams that separate failure from breakdown at the point of logging are, in effect, applying that same lifecycle discipline to their own data.
A functional failure is a failure in which the asset still runs but performs outside its acceptable standard, while a complete failure is one in which the asset can no longer perform its function at all. This mirrors how reliability engineers classify failure severity, and it separates a degraded-but-running pump from one that has seized entirely.
| Severity Level | Functional Failure | Complete Failure |
|---|---|---|
| Asset state | Runs, but outside acceptable performance | Cannot perform its function at all |
| Example | Pump vibrating and overheating but still pumping | Pump seized, output stopped completely |
| Typical trigger | Condition monitoring, sensor threshold, technician note | Breakdown event, emergency work order |
| Urgency signal | Scheduled or condition-based response | Immediate emergency response |
Failures are also tagged with a defined failure mode — wear, fatigue, corrosion, misalignment, contamination, electrical fault, and similar categories — independent of whether the event caused a breakdown. Standardized failure-mode taxonomies mean two technicians on two different shifts describe the same failure the same way, which is the foundation every downstream failure mode report depends on. Most maintenance teams find that once a failure mode list is standardized, the biggest change isn't in how failures get fixed but in how quickly a pattern across multiple assets becomes visible, since a dozen inconsistently worded notes about "acting weird" or "sounds off" never would have surfaced as the same underlying issue.
Cryotos, a Computerized Maintenance Management System, applies what we call the Failure Capture Framework — four checkpoints that turn a raw event into structured, comparable data the moment it's logged.
The Failure Capture Framework:
Maintenance teams using Cryotos apply this framework across eight linked capabilities that keep failure and breakdown data clean, comparable, and useful long after the event is logged.
Cryotos' incident and work order management forms let teams classify an event as a Failure (functional degradation, no stoppage) or a Breakdown (asset down, production halted) at the moment it happens. This single field is the foundation every downstream report depends on, and it's what keeps two technicians on two shifts from describing the same event two different ways. Because the classification happens on a mobile device at the point of capture, it doesn't rely on someone remembering the right terminology hours or days later when a work order gets typed up back at a desk.
Failure mode codes stay consistent across the asset's entire life, whether an event caused a breakdown or not. That consistency is what lets a facility later ask which failure mode is escalating most often across an entire equipment class, rather than just within one machine's history. A wear-related failure on one conveyor and a wear-related failure on another get tagged the same way, so a reliability engineer can pull every wear event across a plant in one report instead of reading through hundreds of free-text notes.
When an event is classified as a breakdown, Cryotos automatically generates an emergency corrective work order, routed by asset criticality and skill requirement. A failure that hasn't caused a breakdown instead routes to a scheduled corrective task, so the urgency and the paperwork match the asset's actual state rather than defaulting to panic mode.
Most maintenance teams find that this single routing rule cuts down the number of failures that get treated as emergencies when they didn't need to be one. It also protects technician time, since a scheduled corrective task can be batched with other planned work on the same asset instead of pulling a crew off another job. Try the MTBF calculator to see how routing accuracy shows up in your own uptime numbers.
Severity in Cryotos is scored on safety and reliability risk, not just on whether the line stopped. A high-severity failure with no downtime — a cracked pressure vessel weld, for instance — still triggers escalation instead of waiting to become a breakdown before anyone is alerted. This matters most in regulated environments, where a safety-relevant condition that never caused a stoppage can still carry more real risk than a low-severity breakdown that was resolved in minutes.
Every asset record shows its full chain: which failures were caught and resolved without a stoppage, and which escalated into a breakdown. Over time this reveals an asset's failure tolerance — how much degradation it can absorb before it actually goes down — which is exactly the input a preventive maintenance strategy needs. A pump with a long history of caught failures and few breakdowns might tolerate a longer inspection interval, while one that breaks down soon after any failure is logged is a strong candidate for tighter monitoring.
Cryotos supports logging a failure that never becomes a breakdown: an abnormal reading, an early warning sign, a near-miss. These records are often discarded by paper-based systems, but they're the leading indicators that let a team intervene before the next failure of the same mode causes an actual stoppage. A technician who notices a slight oil leak and logs it as a degraded-state event, even though the machine keeps running fine that shift, gives the next shift and the reliability team a head start they wouldn't otherwise have.
Whether the event is a failure or a breakdown, technicians attach photos, readings, and condition notes at the moment of capture. This evidence is what lets an RCA later determine whether a breakdown was a sudden failure or the final stage of a failure that had been developing, and visible, for weeks. A photo taken at the point of a functional failure often becomes the single piece of evidence that turns a vague "it just broke" report into a documented, traceable failure progression.
The Cryotos AI dashboard answers questions like "Which failure modes are escalating to breakdown most often?" or "What's our failure-to-breakdown ratio for this asset class this quarter?" — comparisons that are effectively impossible to build manually from a paper log or an undifferentiated event list. Because failure and breakdown data share the same structured fields, the dashboard can also flag an asset class where the ratio is trending in the wrong direction before a manager would ever notice it by reviewing individual work orders.
Separating the two events isn't just cleaner bookkeeping — it changes what root cause analysis, reliability metrics, and cost reporting can actually show a maintenance team.
When failures are logged independently of breakdowns, root cause analysis has a timeline to work with instead of just the moment of stoppage. Investigators can trace a breakdown back to the functional failure that preceded it, sometimes weeks earlier, using methods like the five whys to identify the true root cause instead of the proximate one. Facilities running structured RCA programs typically use a root cause analysis investigation checklist to keep that timeline consistent between investigators, since an investigation that only starts at the moment of stoppage tends to land on the proximate cause — the part that broke — rather than the earlier condition that made the break inevitable.
Mean Time Between Failures calculated from breakdowns alone overstates reliability, because it ignores every failure that was caught and corrected in time. Cryotos calculates MTBF and MTTR from the full failure record, giving managers an accurate picture of how often assets are actually degrading, not just how often they stop. Maintenance teams have reported up to a 30% reduction in unplanned downtime and 25% faster repair turnaround after moving to this kind of full-record tracking. That accuracy matters most when MTBF is used to justify a capital purchase or a staffing decision — a number built only on breakdowns can make an asset look far more reliable than the maintenance team's own daily experience of it.
A high ratio of failures-to-breakdowns on an asset class signals an effective early-detection process. A low ratio, where failures consistently escalate straight to breakdown, signals a detection gap and points directly at where condition monitoring or inspection frequency needs to increase. Tracking that ratio over several quarters turns a one-time reliability snapshot into a trend line — the same kind of evidence a plant manager needs before approving new sensors or a change to inspection frequency.
Downtime should only ever be attributed to breakdowns, not failures — conflating the two inflates downtime figures and misdirects capital planning. Cryotos' downtime tracking module ties cost and duration strictly to breakdown events, keeping failure-rate analysis and downtime-cost analysis as two clean, separate metrics instead of one blurred number. When a functional failure gets miscoded as downtime, a plant's reported availability drops even though the asset never actually stopped producing, which can trigger unnecessary escalation or skew a site's OEE reporting.
Because failure mode is captured whether or not a breakdown occurred, Cryotos can surface a recurring failure mode across an equipment class long before it produces enough breakdowns to be noticed manually. That earlier visibility shifts the PM schedule ahead of the pattern instead of reacting after it, and it's the same principle behind condition-based maintenance programs more broadly. A facility running twenty identical pumps, for example, can spot a corrosion pattern showing up across five of them long before any of those five actually seize.
For regulated industries, auditors expect to see that safety-relevant failures were identified and acted on, not just that a breakdown eventually happened. According to ASQ's guidance on failure mode and effects analysis, documenting failure severity independently of the eventual outcome is a core part of a defensible quality and safety program. Cryotos' separation of failure and breakdown records gives compliance teams that same time-stamped account of early detection and response, which matters during an audit where the question isn't just "did something break" but "did your team know, and when."
Labor, parts, and contractor costs can be rolled up to the specific failure mode that ultimately caused a breakdown, not just the breakdown event itself. Over time, this shows which failure modes are the most expensive across an asset's life, not just which stoppages were the most disruptive — a distinction reliability engineering practitioners increasingly rely on for capital planning. A failure mode that rarely causes a dramatic breakdown but requires expensive parts every time it's caught can end up costing more across a year than the one dramatic stoppage that gets all the attention.
The same failure-then-breakdown pattern shows up differently depending on what an asset does and how forgiving its process is of a partial loss of function.
On a production line, a functional failure often shows up as a quality drift — a stamping press producing slightly out-of-tolerance parts — long before it causes an actual line stop. Teams that log that drift as a failure event, rather than waiting for the press to jam, get a head start on the tooling replacement before it becomes an unplanned stoppage.
In upstream and heavy-equipment environments, a functional failure like a slow hydraulic leak or a rising bearing temperature can be tolerated for a defined window under a maintenance plan, but it still needs to be logged the moment it's detected. If that same asset later suffers a complete failure and a breakdown, the earlier failure record is what lets an investigation show how long the condition existed and whether the response time met policy.
In food and beverage plants, a functional failure in a refrigeration or sanitation system carries risk even when the line never actually stops, because a temperature excursion can compromise product safety without ever triggering a full breakdown. Logging that as a failure event, independent of downtime, is often what a compliance audit is specifically checking for.
No. A failure is the loss of an asset's required function, partial or complete, while a breakdown is the operational stoppage that a severe failure can cause. Every breakdown starts from a failure, but most failures are caught or resolved before they ever become one.
Yes. A functional failure — like a motor running hot or a bearing vibrating outside spec — can exist for days or weeks while the asset keeps running, as long as it's caught and addressed before it escalates into a full stoppage.
Because a system that logs only breakdowns misses every failure that was caught early, which overstates reliability and hides the leading indicators — like recurring failure modes — that predictive maintenance programs depend on.
A breakdown automatically triggers an emergency corrective work order routed by asset criticality, while a failure that hasn't caused a breakdown routes to a scheduled corrective task, so response urgency matches the asset's actual condition.
It's the proportion of logged failures on an asset class that were caught before they caused a stoppage. A high ratio signals effective early detection, while a low ratio points to a gap in condition monitoring or inspection frequency.
Not always. A minor functional failure caught during an inspection might get folded into the next scheduled preventive maintenance visit rather than generating a standalone work order, as long as the failure and its mode are still logged for trend tracking. What matters is that the event is captured somewhere in the system, not that it always produces a separate ticket.
The deciding factor is whether the asset stopped performing its function. If it's still running, even in a degraded state, it's a failure. If production has actually halted or an emergency response was required, it's a breakdown. A CMMS with a single mandatory classification field at the point of logging removes most of the guesswork, since the technician only has to answer whether the asset is still running.
Breakdown and failure describe two points on the same timeline: one is the degradation, the other is the consequence severe enough to stop the asset. Facilities that keep logging them as if they were interchangeable end up managing their maintenance program on incomplete data, no matter how good their technicians are in the field. Schedule a free demo to see how Cryotos captures both and turns the gap between them into a clear signal of how much warning your team is actually getting before an asset goes down.
Cryotos AI predicts failures, automates work orders, and simplifies maintenance—before problems slow you down.
