The 5 Whys template for chronic downtime (with a worked example)

A recurring stop almost never has the cause you write on the downtime log. "Die jam," "sensor fault," "operator error" — those are symptoms. The 5 Whys is the simplest tool for getting past the symptom to something you can actually fix, and you can run it in ten minutes at the machine with a pen and this template. This guide gives you the template, shows you how to fill it in on a real downtime problem, and points out the mistakes that make most 5 Whys sessions stall at "we need to be more careful."

What the 5 Whys is, and what it is not

The 5 Whys is a root cause technique: you state the problem, then ask "why did that happen?" and keep asking until you reach a cause you can remove — usually a broken or missing process, not a broken part. Five is a rule of thumb, not a quota. Sometimes you get there in three whys; sometimes it takes seven. Stop when the next "why" would leave your shop floor and turn into a philosophy question.

It is not a blame tool. The moment a chain ends at "the operator wasn't paying attention," you have stopped one level too early. People are rarely the root cause; the process that let a mistake reach the machine usually is. A good 5 Whys ends at something a supervisor or engineer can change by Friday: a checklist item, a setpoint, a fixture, a training standard, a spare-parts rule.

When to reach for it

The 5 Whys works best on a single, repeatable failure mode — one recurring stop you can describe in a sentence. It is weak on vague, tangled problems with many interacting causes; for those, use a fishbone diagram to spread the possibilities out first, then run a 5 Whys on the one or two branches that matter most.

So the honest workflow is: track every stop, build a downtime Pareto to find the handful of causes eating most of the minutes, and point the 5 Whys at the top bar. Running root cause analysis on a cause that only costs you nine minutes a month is a waste of a good meeting.

The 5 Whys template

Copy this into a notebook, a shared doc, or a printed shop-floor form. The right-hand column is the one people skip and the one that matters — a 5 Whys with no verification is just a group guess.

Two rules make it work. First, each "why" must be the direct cause of the line above it — read it back as "[lower cause], therefore [upper cause]" and check it actually holds. Second, prefer a fact you can confirm over a theory you like. If a "why" is a guess, go confirm it at the machine before you build the next why on top of it.

A worked example: a recurring stop on a stamping line

Here is one week of downtime on Line 3, a progressive-die stamping line, sorted into a Pareto:

The die-protection trip is the clear number one: 42 stops and 210 minutes in a single week, more than a third of all downtime. "Die-protection trip" is a symptom, though — the sensor did its job. So we run a 5 Whys on it.

Notice where the chain didn't stop. "The feed roll slipped" (why 2) is a tempting place to quit — you could just tell maintenance to replace the feed roll. But the roll wasn't worn; the pressure was wrong, and it was wrong because of a drifting regulator nobody watched. Replacing the roll would have cost a part and a changeover and changed nothing, because the next shift's regulator drift would start the stops all over again. The real fix was a line on a checklist and a mark on a gauge — nearly free.

The verification step is what separates this from a guess. The week after the checklist and gauge mark went in, die-protection trips dropped from 42 to 7, and weekly downtime on the line fell by roughly 180 minutes. If the number hadn't moved, that is a signal the chain was wrong somewhere and you reopen it — which is exactly why you write the target down before you start.

Common mistakes that make the 5 Whys fail

Stopping at a person. "Operator didn't check it" is a why-2 answer dressed up as a root cause. Keep going: why was it possible to skip the check? Usually there was no check to skip.
Jumping to the fix you already wanted. If the chain conveniently ends at "we need the new machine we've been asking for," be suspicious. Build the chain from facts, not from the budget request.
One chain for a tangled problem. If the stop has three genuinely different causes, a single line of whys will chase one and ignore the other two. Spread them out with a fishbone first, then run a 5 Whys per major branch.
No verification number. Without a before/after metric from your downtime log, you can't tell a real fix from a coincidence, and the problem quietly comes back.
Running it from memory. If you're reconstructing last Tuesday's stop from memory, you're guessing. Run the 5 Whys against logged data — timestamps, reason codes, and operator notes — not against what people think happened.

Make the answer stick

A root cause analysis is only worth the time if the corrective action actually gets done and you can see whether it worked. That means the finding has to live somewhere other than a photo of a whiteboard. The practical pattern is: log the stop when it happens, categorize it so it rolls up in a Pareto, and attach the corrective action to that reason code with an owner and a due date, so it stays open until somebody closes it.

This is where tracking software earns its keep. In HelpFab's downtime tracking, operators log each stop from a phone or tablet on the floor, every stop carries a reason code, and the Pareto report ranks the causes for you. From the top bar of that chart you create a follow-up on the reason code: the corrective action as the title, the 5 Whys chain and root cause in the notes, an owner, and a due date. It sits in the open follow-ups list until the owner marks it complete, so the action doesn't evaporate at the end of the shift — and because every future stop is still being logged under the same reason code, your verification number builds itself.

If you're not on a tool yet, you can run the whole loop in a spreadsheet to start — our free downtime tracking Excel template has the reason-code list and a pivot that builds the Pareto, which is enough to pick the right problem and measure the fix.

Copy this and run one this week

Pick your top downtime cause from last week's Pareto, grab the template above, and run one 5 Whys at the machine with the people who were there. Keep asking why until you reach something you can change by Friday, write down the corrective action with an owner, and set the before/after number. One good root cause a week, verified against your downtime log, compounds fast — far faster than firefighting the same stop forty times.

Latest articles

A fishbone diagram template for chronic downtime (with a worked example) — A ready-to-use 6M fishbone template for chronic manufacturing downtime, with a worked molding-line example that sorts causes and points at the real fix.
How to track downtime on older machines without a PLC — No controller, no sensors, no problem. A practical way to capture downtime on legacy machines using operator logging and a short reason-code list — and how to decide when automatic capture is worth adding.
CMMS vs downtime tracking software — A CMMS manages assets and work orders; downtime tracking logs every production stop. Different jobs, not competitors — here is when a small shop needs each.
An andon system for a small shop, without the light tower — A low-cost andon for a small shop - what to signal, how to escalate, and how each call becomes a downtime log entry you can actually act on.
Track changeover time first, then SMED it down — Measure changeover time before you improve it - split internal from external work, see a worked die-change breakdown, and learn exactly what to log.
A production downtime report example, daily and weekly — A worked production downtime report for a CNC cell, the four numbers managers actually read, and a layout that turns lost minutes into action.
MTTR and MTBF: how to track them from your downtime log — Track MTTR and MTBF from your downtime and maintenance logs - the formulas, a worked quarter on one machine, and the mistakes that corrupt both numbers.
Maintenance log vs downtime log — Maintenance log vs downtime log - what each one captures, why a plant needs both, and how a single breakdown links them to give you MTTR and MTBF.
Choosing a downtime tracking app for a small manufacturer — What a small shop should look for in a downtime tracking app: phone logging, configurable reason codes, and reports you can read without an ERP.
How to reduce unplanned downtime in manufacturing — A track-first playbook to reduce unplanned downtime - log every stop, Pareto the causes, then attack the vital few with PM and root-cause fixes.
How to calculate the cost of unplanned downtime — A cost-per-hour formula for unplanned downtime, with a worked molding-cell example covering labor, scrap, lost margin, and overhead.
A free downtime tracking Excel template (and how to actually use it) — A free Excel downtime log template — the columns, a reason-code list, and the pivot that turns raw stops into a Pareto, plus when to move off it.
OEE availability: how to calculate it from your downtime data — Calculate OEE availability from your downtime log, with a worked CNC example — plus the reclassification tricks that quietly inflate the number.
How to build a downtime Pareto analysis — Build a downtime Pareto step by step with a worked stamping-line example that finds the few causes driving most of your lost minutes.
A practical machine downtime reason code list — A starter taxonomy of machine downtime reason codes — planned vs unplanned, with real fault-code examples and rules that keep operators logging honestly.
Downtime tracking spreadsheet vs software — When an Excel downtime tracker is enough and when it quietly breaks — a shift-by-shift comparison for small manufacturers, with a real cost example.
How to track machine downtime — Move from a paper downtime log to structured tracking: reason codes, who logs what, and the three reports that actually change decisions.