Same machine, five descriptions: why repeat faults never add up

Short answer: Repeat breakdown analysis fails when the same fault is written five different ways. Group the records by machine first, not by description. Anchor them with the fault history the drive or control already keeps, sort each record into a short symptom family after the fact, then count. The repeats show up once the words stop hiding them.

Applies to: maintenance and service teams with job cards, downtime logs or service reports for the same machines over months. Worked examples use the fault histories of the Siemens MICROMASTER 440, Yaskawa A1000, ABB ACS580 and FANUC 30i/31i/32i-B, as covered in our earlier posts. Last verified: 31 Oct 2026. Author: Muhammed Fahiz

What does a repeat fault look like in the records?

Usually it doesn't look like anything. Take one conveyor drive over a few months. The records might read:

Date	Who wrote it	What the record says
Week 2	Night shift	Conveyor stopped, reset, running
Week 5	Electrician	Drive tripped, OC
Week 9	Contractor	F0001, checked motor, OK
Week 12	Day shift	Motor overload? Restarted
Week 15	Downtime log	Other

Our illustration, not real records.

Read one line at a time, each looks like a small, closed job. Read together, it could be the same overcurrent trip five times. Nothing in the records says so, because no two lines share a word.

Nick Nickolovski described exactly this in a comment on a public LinkedIn post by Delin S. in October 2026:

"Often the repeat offender hides in "Other" on the downtime log. Same machine, five different descriptions, so it never adds up to one problem." (Nick Nickolovski, comment on Delin S.'s LinkedIn post)

Why do repeat faults never add up?

Because nothing in the record ties them together. Delin S.'s post opens with the pattern: "Maintenance keeps fixing, but the same machine keeps breaking. That is not just a maintenance problem. It is a memory problem." When repair history lives in scattered places, he lists what follows, including "Repeat failures go unnoticed" and "Preventive actions get skipped because the pattern is invisible." His summary line is the one we quoted in "It's running now" is not a fix: "A repair you cannot look up is a repair you are likely to repeat."

Another commenter, Andrew Nonchev, put the mechanism in one sentence: "If a repair isn't tied to an asset ID and a failure code, you cant search for it, and if you cant search for it you never see it repeating."

In practice three things keep the five records apart:

• Different words. "OC", "F0001", "overload" and "stopped" can all describe one trip. A search or a filter for any one of them misses the rest.
• No firm machine identity. "Conveyor", "Line 2", "the drive by the dock" and a serial number may all be the same asset, or not.
• A catch-all bucket. "Other" and "misc" are where records go when the form has no better option and the shift is busy. Nobody reviews them, so whatever repeats there stays hidden.

None of this is carelessness. Each person wrote a reasonable line in their own words. The problem only appears when you try to add the lines up.

How do you find the repeat offenders in records you already have?

Start with one machine or one line, a fixed window (say a quarter or six months for a first pass), and every record you can find. Then work in this order.

1. Pull everything for the window. Job cards, the downtime log including "Other", contractor service reports, AMC visit reports, shift handover notes, and the chat messages people actually use. A repeat often has one visit in each place.
2. Group by asset, not by description. Decide which records belong to which physical machine: serial number first, then asset tag, then location. Write the asset next to each record. This is the step that turns five stories into one list.
3. Anchor the list with the machine's own fault history. Drives and controls keep a log that doesn't depend on anyone's wording. A Siemens MICROMASTER 440 keeps recent fault codes in r0947. A Yaskawa A1000 shows the ten most recent faults in U3-01 to U3-10. An ABB ACS580 logs the last 32 faults with time stamps. A FANUC 30i-B alarm history lists alarms with date and time. Match each written record to a logged fault by date or running hours where you can. Our post on finding the alarm someone already solved three years ago covers where each history lives and how it gets cleared.
4. Sort each record into a symptom family after the fact. Don't rewrite the originals. Add one column with a short family name your team agrees on, such as "drive overcurrent trip", "hydraulic pressure low" or "sensor not made". Use the logged fault code where there is one, and the symptom words where there isn't.
5. Count per asset and per family, then sort. The machine-and-family pairs at the top are your repeat candidates. Agree on what counts as a repeat (for example, the same family on the same asset twice in the window) before you look, so the rule doesn't bend to fit a favourite theory.
6. Read each repeat as one story, in date order. What was tried each time, what cleared it, and how long it held. Five "reset, running" lines in a row tell you the cause was never found.

Applied to the illustration above, it looks like this:

What the record says	Asset	Logged fault (from the drive history)	Symptom family
Conveyor stopped, reset, running	Conveyor 2 drive	F0001	Drive overcurrent trip
Drive tripped, OC	Conveyor 2 drive	F0001	Drive overcurrent trip
F0001, checked motor, OK	Conveyor 2 drive	F0001	Drive overcurrent trip
Motor overload? Restarted	Conveyor 2 drive	F0001	Drive overcurrent trip
Other	Conveyor 2 drive	F0001	Drive overcurrent trip

Our illustration. In real records some lines won't match a logged fault, and some families will be a judgement call. Mark those, don't force them.

Five records, one problem. The diagnosis can now start from the trip conditions written across all five visits, which is where our guide to isolating a VFD overcurrent trip picks up.

How do you get consistent failure codes without turning technicians into typists?

Make the consistent part the part nobody has to type. Nickolovski asked this in the same comment: "Has anyone found a way to get consistent failure codes without turning technicians into typists?" We don't have a universal answer, but these are the parts that need the least typing:

• Copy the code the machine already gives you. A drive or control fault code is the most consistent description you'll get, because the machine wrote it. A photo of the fault screen with one line saying which machine it is works too.
• Fill in the asset before the technician arrives. If the job is raised against a serial number or asset tag, nobody has to describe the machine.
• Keep the symptom list short. A handful of families per machine type, chosen from what actually breaks, is usable at the machine. A long tree of codes ends in "Other".
• Make "Other" ask for one word. "Other: belt" is something you can count later. "Other" alone isn't.
• Leave one free-text line. What was tried and what cleared it still need the technician's own words. That's the line the next person reads.
• Re-code weekly, not at the machine. A supervisor or planner can sort last week's records into families. The technician's job is to write what happened, not to classify it.

The idea of a shared failure vocabulary isn't new. ISO 14224, the reliability and maintenance data standard for the petroleum, petrochemical and natural gas industries, describes its terms as a "reliability language" and its failure modes as a "reliability thesaurus", and separates equipment data, failure data and maintenance data. Most plants and machine builders don't need the full standard. The useful part to borrow is the split: which machine, what failed, what was done.

Is a repeat fault a memory problem or a process problem?

Often both, and the record is what lets you tell them apart. Not every commenter on Delin S.'s post agreed with the framing. Kevin Bruce wrote: "This is not a memory problem. This is process failure problem. That's a lack of accountability." Duane Utter listed causes no record will fix on its own, starting with "Operators continuously damaging equipment through misuse, neglect, and ignorance." Dave Trevor-Roberts pointed out that with no redundancy and purely reactive maintenance, "You will never be able to eliminate the root causes, even if you have records and resources."

They're right that a searchable history doesn't remove the cause. What it does is show which machines to look at and what has already been tried. Five overcurrent trips after every product change point somewhere different from five trips at random. You can only see that difference if the five records line up.

Teodora Terzieva's comment is the test we'd use for whether your records are good enough: "Who fixed it last time? If the answer is a name and not a record, that knowledge goes on holiday every time the person does."

What should change once the repeats are visible?

Three things, mostly small.

• Close each repeat job against the earlier ones. The new report should say "same as the visits on these dates" and what was different this time. Our close-out checklist in "It's running now" is not a fix lists the six fields that make that possible.
• Treat a third "reset, running" as a finding. It means the cause is still open. That's the point to do a proper root cause analysis on that machine, not on every breakdown.
• Look on sister machines. If the same family shows up on another unit of the same model, the earlier fix may already be written down there. Our guide on how to find a past service fix for a repeat machine fault covers where those fixes usually live.

Where does HangerSearch fit?

The counting in this post is a spreadsheet job. The slow part is step 1 and step 6: finding the earlier reports, then reading what was actually tried. HangerSearch is private, retrieval-only search over your team's own finalized service reports, searched where they already are. You search by fault code, model or symptom. It shows the prior reports that match and why each matched, and opens the cited page. Nothing is generated, and if there's no similar report, it says so. See how we handle your reports.

Book a 20-minute demo: hangersearch.com

FAQ

What is repeat breakdown analysis?

It's finding the machines that keep failing in the same way and reading those failures together. In practice that means grouping breakdown records by asset, sorting each one into a symptom family, counting, and then reading the top repeats in date order to see what was tried and what came back.

Why don't repeat faults show up in our downtime reports?

Usually because the same fault is described differently each time, the machine isn't identified consistently, or the record went into "Other". Each line looks like a separate job. Grouping by asset first, then sorting into symptom families, makes the pattern visible.

How do you get consistent failure codes from technicians?

Ask for as little typing as possible. Copy the fault code the drive or control displays, raise jobs against the asset so it doesn't need describing, keep a short symptom list per machine type, and have a supervisor sort records into families each week. Keep one free-text line for what was tried and what worked.

When does a repeat breakdown need a root cause analysis?

When the record shows the same symptom family on the same machine coming back after "reset, running" style fixes. Agree the threshold as a team, for example twice in a quarter, and apply it before you look at the data.

Sources

1. Delin S., public LinkedIn post, "Maintenance keeps fixing, but the same machine keeps breaking." (11 Oct 2026), with comments by Nick Nickolovski, Andrew Nonchev, Teodora Terzieva, Kevin Bruce, Duane Utter and Dave Trevor-Roberts (12 Oct 2026): https://www.linkedin.com/posts/delinsirkov_maintenance-cmms-reliability-activity-7514852511011463168-0mhw. Read 31 Oct 2026. Supports: all quotes in this post.
2. ISO, "ISO 14224:2016 Petroleum, petrochemical and natural gas industries - Collection and exchange of reliability and maintenance data for equipment", abstract: https://www.iso.org/standard/64076.html. Read 31 Oct 2026. Supports: scope, "reliability language", "reliability thesaurus", and the equipment / failure / maintenance data categories.
3. Siemens, MICROMASTER 440 Parameter List, 6SE6400-5BB00-0BP0, Issue 01/06, p. 106. Supports: r0947 fault codes.
4. Yaskawa, A1000 Technical Manual, SIEP C710616 27C, p. 450. Supports: U3-01 to U3-10 most recent faults.
5. ABB, ACS580 Standard Control Program Firmware Manual, 3AXD50000016097 Rev J, p. 538. Supports: the last 32 fault recordings.
6. FANUC, Series 30i/31i/32i-MODEL B Maintenance Manual, B-64485EN/01, p. 136. Supports: alarm history with date and time.