Equipment Failure Records: The Reliability Data Model

What is an equipment failure record?

An equipment failure record is the structured documentation of a single failure event on a single asset. It answers what failed, how it failed, why it failed, how long it was down, what was done to fix it, and what parts were consumed. One record equals one breakdown, timestamped and coded so it can be counted, sorted, and analyzed later.

A failure record is not the same as a work order. The work order is the instruction to do the repair. The failure record is the reliability evidence the repair leaves behind.

Without accurate failure data, a CMMS is little more than a work order ticket system, and without failure modes its codes say little about how equipment actually fails. The record is what turns a closed ticket into data you can learn from.

This matters because nearly every reliability metric your plant reports is built on these records. If the records are vague, guessed, or inconsistently coded, then MTBF, MTTR, and the availability component of OEE are all built on sand.

Which fields belong in an equipment failure record?

A complete failure record captures the asset, the failure itself, the timing, the response, and the resources. Missing any one of these breaks a downstream calculation. The table below shows the core fields, what each one feeds, and the common failure of that field.

A subtle but critical point: downtime and time to repair are different fields. Downtime is the full clock from stop to restart, including waiting for a technician and waiting for parts. Time to repair is the active repair work only. Storing them separately is what lets you later distinguish a slow-to-respond problem from a hard-to-fix problem.

Why must failure mode and cause be separate fields?

Because the failure mode is what a technician observes and the cause is what they infer. The mode is usually correct. The cause is often a best guess. If you merge them into one box, you can never tell a reliable observation from a hopeful assumption, and your data quality silently degrades.

Keeping them apart also enables the most valuable reliability question of all: does the same mode keep recurring from the same cause? The trap is familiar: a new bearing goes in, the true cause is never resolved, and the replacement fails the same way a few months later. Separate fields are what surface that pattern.

What is a failure code and why does taxonomy matter?

A failure code is a standardized, dropdown-selectable value that classifies a failure instead of describing it in free text. A coded taxonomy turns thousands of breakdowns into a countable dataset. Free text turns them into a pile of unsearchable notes.

The reference standard here is ISO 14224 , the international standard for the collection and exchange of reliability and maintenance data for equipment.

It defines a common reliability language: a layered equipment taxonomy plus standardized failure-data categories covering equipment data, failure data such as failure cause and consequence, and maintenance data such as maintenance action and down time.

Even outside oil and gas, where it originated, ISO 14224 is the benchmark for how to structure failure records so they pool into one statistically valid dataset ( ISO 14224:2016 ).

The practical lesson for any plant: build a controlled vocabulary of failure modes and causes per equipment class, enforce it with dropdowns, and make the failure-mode field mandatory before a corrective work order can close. That single rule does more for data quality than any analytics tool.

How do failure records feed MTBF, MTTR, and OEE?

Failure records are the input data for the headline reliability metrics. Each metric is a simple ratio, but every term in that ratio comes straight off your records, which is exactly why record quality determines metric quality.

The formulas are deliberately simple. MTBF is total uptime divided by the number of failures, and MTTR is total repair time divided by the number of repairs ( LogicMonitor ). Notice that both depend on an accurate count of failures.

If small stops go unrecorded, your failure count is too low and MTBF looks artificially good. If downtime timestamps are sloppy, availability is wrong. For a deeper treatment, see our guides on MTBF and MTTR and on unplanned downtime .

How do clean records enable FMEA and reliability analysis?

A Failure Mode and Effects Analysis is only as good as the failure history it is built from. FMEA ranks risks using severity, occurrence, and detectability. Your failure records supply the real-world occurrence data (how often each mode actually happens) and the detection data (how the failure was found). Without coded records, those scores are opinions. With them, they are evidence.

Clean records also drive asset criticality ranking and let you build a data-led preventive maintenance program instead of a calendar-based guess. A recurring failure mode on a critical asset is the textbook trigger to convert reactive repair into a planned PM task.

What are the most common failure-record data-quality problems?

The most common problem is the guessed cause: a technician closes the job, picks a plausible cause from the dropdown, and moves on. The second is missing records entirely, where short stops never get logged. Together they corrupt both the cause data and the failure count, which is why so many CMMS installations never produce a usable failure analysis.

Use this checklist to audit your own failure-record discipline:

• Mandatory failure mode on every corrective work-order close, selected from a controlled list.
• Separate fields for failure mode, cause, and action taken, never one merged note.
• Timestamps captured at the event, not reconstructed from memory at shift end.
• Short stops counted, so the failure count is real (see the six big losses framework).
• A controlled taxonomy per equipment class, ideally aligned to ISO 14224 structure.
• Cause based on evidence, not the most convenient dropdown value.

How does Fabrico keep failure records accurate, not guessed?

Most CMMS failure records are typed in after the fact by a technician who is reconstructing what happened. Fabrico changes the source of the data. Because Fabrico connects directly to machine PLCs, the downtime start and end timestamps are captured automatically from the line, not entered by hand, so the availability data feeding OEE is precise rather than rounded.

For the hardest field of all, the cause, Fabrico can capture the stop itself on video at the moment it occurs, so the technician confirms the cause from the footage instead of reconstructing it from memory. That tackles the single biggest data-quality risk in any reliability data model: a guessed cause logged hours later.

The stop can then trigger a follow-up task on the technician's phone, with QR-enforced checklists, so the corrective action and the spare parts used are recorded against the work order as the job is done, not remembered afterward.

The result is a closed fault-to-fix loop where the failure record is a byproduct of the work, not an afterthought. As an EU-built platform with EU data residency, Fabrico keeps that reliability data inside a clear governance boundary.

If your failure records are full of guessed causes and rounded timestamps, your MTBF and OEE numbers are guesses too. See how Fabrico captures every stop and turns every breakdown into clean, analysis-ready data.