A breakdown log that actually tells you something

Open your breakdown log and pick a week at random. You'll probably see something like this.

"Line 3 down. Reset. Running." "Wrapper fault. Fixed." "Conveyor stopped. Adjusted sensor. OK."

Every entry is true. None of them tells you anything. You can't tell how long the line was stood, what the fault was, what fixed it, or whether it's the same fault as last Tuesday. Six months of entries like that and you have a log that proves your team was busy, and nothing else.

Most sites keep a log. Very few keep one they can use.

What the log is for

There's no legal duty to keep a maintenance log on most kit. HSE's code of practice for PUWER says so, though it recommends you keep a record of maintenance for high-risk equipment (L22, paragraph 78). If a machine does have a log, PUWER requires that you keep it up to date (regulation 5).

So the law won't tell you what to write. The useful reason is the one the code of practice gives. A detailed log "can provide information for future planning of maintenance activities" and tells your people "what actions have been taken previously" (L22, paragraph 78).

In plain terms, a good log does three jobs. It tells the next engineer what was done. It shows you the faults that keep coming back. And it gives you the numbers when you go to the board for money.

Ten things every entry needs

Keep it short. A form nobody fills in is worse than a short one everybody does. These are the fields we'd use:

1. Machine, and the part of it. "Line 3 case packer, infeed" beats "Line 3".
2. Time it stopped, and time it was back running
3. Who found it, and who fixed it
4. What the operator saw. Alarms, noise, smell, what it was doing.
5. The fault code from the HMI, word for word
6. What was found. The actual cause, as far as you know it.
7. What was done. Part changed, setting changed, reset only.
8. Parts used, and whether they came off the shelf or another machine
9. Fixed or patched. Is this a proper repair or a temporary one?
10. Anything left to do, with a name on it

Two of those matter more than the rest. Time stopped and time running gives you the downtime. "Fixed or patched" tells you which machines are running on bodges. Our post on temporary fixes that become permanent explains why that column matters.

Write the cause, not the action

"Changed sensor" is an action. "Sensor cable crushed by guard on refit" is a cause. The first tells you nothing next time. The second tells you the guard needs a cable clip, and that the next fitter should check the cable before ordering a sensor.

Ask your team for the cause, even when they're not sure. "Suspect bearing on tail pulley, not confirmed" is still useful. A guess written down can be checked later. A guess kept in someone's head is gone when the shift ends.

Watch for "reset" with nothing after it. A reset clears the fault. It doesn't find it. If the log is full of resets on one machine, you have a fault nobody has found yet. We've written about reset and run as a habit.

Log the small stops too

The ten-minute stops are where the hours hide. A sensor that drops out four times a shift, cleared by the operator each time, never makes the log. Add it up over a month and it can be more downtime than the big breakdown everyone remembers.

So set a low bar for logging. If the line stopped and someone had to do something to start it, it goes in. Operators can log their own short stops on a simple sheet by the machine. Our post on micro-stops goes into this.

Make it easy at 3am

The log fails at the worst time: nights, with one fitter, a stopped line and a shift manager waiting. If filling it in takes ten minutes, it won't get done until morning, and by then the details are gone.

So make it quick. A tablet or phone form with drop-downs for the machine and the fault type, and a box for the cause. A photo of the HMI attached instead of typing the alarm list. If you use a CMMS, set it up so a breakdown can be logged in under two minutes. Our post on getting engineers to use the CMMS covers the rest.

Then make sure someone reads it. A log nobody reads soon turns into "Fixed. Running." again.

Read it every week

Here's our view. The log only earns its keep if someone sits down with it every week. Fifteen minutes is enough.

Look for three things:

• Repeats. The same machine with the same fault more than twice in a month. That's a root cause job, not another reset. Our post on the fault that keeps coming back covers how to run one.
• Long fixes. Breakdowns that took far longer than they should. Was it a spares problem, a skills problem, or a nights problem? Each has a different fix.
• Skills gaps. Faults that waited for one person, or were passed on to the next shift because nobody on shift could do them. Those tell you where you need cover, or training.

That third one is the hardest to see without a log. If the drive faults on nights always wait for the day electrician, the log will show it. So will the downtime. Those lost hours put a number on the gap. That's the number to take to the board when you ask for another engineer or for outside cover.

Turn it into numbers

After three months of good entries, you can work out your mean time to repair for each machine. Add up the downtime and divide by the number of breakdowns. Our post on mean time to repair explains why that's the number to watch.

Multiply the downtime by what an hour stopped costs you, and you have a list of your most expensive machines. That's the start of a case for spend.

What to do on Monday

1. Pull last month's breakdown log and count how many entries say what the cause was.
2. Agree the ten fields with your team, and cut any your form has that nobody fills in.
3. Book fifteen minutes every week to read the log, and list the repeats.
4. Mark every entry where a fault waited for one person. That's your skills gap list.

* Paragraph numbers refer to L22, fourth edition (2014, amended 2018).