A fishbone diagram template for chronic downtime (with a worked example)

Some downtime problems are simple enough to chase down one line of questions. Others are tangled — a recurring stop that could be the machine, the material, the method, or three of them at once. For those, a single chain of "whys" picks one suspect and ignores the rest. The fishbone diagram is the tool that spreads every possible cause out in front of you first, so you investigate the right branch instead of the first one that comes to mind. This guide gives you a copyable 6M fishbone template, walks it through a real chronic-downtime problem on a molding line, and shows how to turn the diagram into a fix you can verify.

What a fishbone diagram is

A fishbone diagram — also called an Ishikawa or cause-and-effect diagram — is a structured way to brainstorm the causes of one problem. You write the problem in a box on the right (the fish's head), draw a spine to it, and hang major cause categories off the spine as angled bones. Under each category you list the specific causes the team can think of. The result looks like a fish skeleton, and it forces you to consider every type of cause before you commit to investigating one.

The point is breadth, not depth. A fishbone does not tell you the root cause — it lays out the candidates so you can rank them, test the likely ones, and drill into the winner. It is a map of where to look, drawn before you start looking.

The 6M categories for manufacturing

Most shops use the 6M framework for the major bones, because the six categories cover almost every way a machine can stop:

You don't have to use all six. If a category genuinely has nothing under it, leave the bone empty rather than inventing a cause to fill it.

Machine — equipment, tooling, fixtures, and their condition. Worn parts, drifting setpoints, failing sensors.
Method — the process and procedure. Cycle settings, sequence, changeover steps, standard work that is missing or wrong.
Man (people) — skills, training, staffing, and handoffs. Not blame — gaps in what people were given to work with.
Material — incoming stock, consumables, regrind, lubricants. Variation in what feeds the machine.
Measurement — gauges, sensors, and the data itself. If you can't trust the reading, you can't trust the cause.
Environment (sometimes called Mother Nature) — temperature, humidity, dust, vibration, floor space.

When to reach for a fishbone instead of a 5 Whys

The two tools are partners, not rivals. A 5 Whys is best when the failure is a single, repeatable mode you can describe in one sentence — you follow one cause chain straight down to a changeable process. A fishbone is best when the problem is vague or has several plausible, competing causes that need sorting before you can pick one to chase.

The honest workflow uses both. Track every stop, build a downtime Pareto to find the handful of causes eating most of your minutes, and point your analysis at the top bar. If that top cause is tangled, spread it out with a fishbone first, then run a 5 Whys on the one or two branches that look most likely. The fishbone decides where to drill; the 5 Whys does the drilling.

The fishbone template

Copy this into a whiteboard, a shared doc, or a printed shop-floor form. Fill the problem statement first, then work the categories one at a time with the people who run the machine.

Two rules make it work. First, write causes, not symptoms — "barrel temperature drifts during the shift," not "bad parts." Second, mark the bones you can confirm with data versus the ones that are guesses, because the next step is to go test the guesses, not argue about them in the room.

A worked example: chronic stops on an injection molding cell

Start with a Pareto so you pick the right problem. Here is one week of downtime on Cell 7, an injection molding machine running a filled-nylon part:

"Short shot / quality reject" is the clear number one: 31 stops and 186 minutes in a week, over 40% of all downtime. But it is a tangled problem — a short shot can come from the machine, the material, the method, or the environment, and the operators already disagree about which. This is exactly the problem a fishbone is built for, so we spread it out:

Six bones, thirteen candidate causes — far more than a single 5 Whys would have surfaced. Now rank them. The team circles three top suspects using what the downtime log already shows: the timestamps put 24 of the 31 short-shot stops on night shift (points at Man — restart profile), the dryer hour-meter is well past its desiccant-change interval (Material — moisture), and the check ring was last replaced 400,000 shots ago (Machine — wear).

Testing beats arguing. A quick shot-weight check confirms parts run 2.1 grams light on nights versus days, and the saved night profile has a shot size 4 mm shorter than the day profile, so the screw bottoms out with no cushion left to pack the part — someone's "fix" from a previous jam that never got corrected. The moisture and check-ring theories stay on the list but drop to second and third, because the profile difference is confirmed data, not a guess.

With the tangle sorted, point a 5 Whys at the winning branch — the wrong restart profile — and it reaches a changeable process fast: there is no standard restart, each operator loads whatever profile they trust, and the night profile was edited during a bad shift and never reset. The corrective action writes itself.

The week after the profile was locked, short-shot stops on Cell 7 fell from 31 to 8, and weekly downtime on the cell dropped by roughly 140 minutes. The dryer and check-ring actions stayed open as insurance against the next drift. If the number hadn't moved, that's the signal to reopen the fishbone and work the second suspect — which is why you write the target down before you start.

Common mistakes that make a fishbone fail

Treating it as the answer instead of the map. The diagram lists candidates; it doesn't rank or confirm them. If you walk out of the room without choosing top suspects and a test, you've only brainstormed.
Filling every bone to look thorough. An empty Environment branch is fine. Inventing a cause to balance the fish just adds noise to the ranking.
Writing symptoms, not causes. "Bad parts" and "machine stops" belong in the fish head, not on a bone. The bones are the reasons those happen.
Guessing from memory. If you can't say how many stops and minutes the problem costs, you're reconstructing it from impressions. Build the fish head from logged data — reason codes, timestamps, operator notes.
Never verifying. Without a before/after number from your downtime log, you can't tell a real fix from a coincidence, and the problem quietly returns.

Make the diagram turn into a fix

A fishbone is only worth the meeting if the chosen action 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 under a reason code 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 someone 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 — so you point the fishbone at a real top bar, not a hunch. From that chart you open a follow-up on the reason code: the corrective action as the title, the fishbone's top suspects and your chosen fix in the notes, an owner, and a due date. It stays in the open follow-ups list until the owner marks it complete, and because every future stop is still logged under the same reason code, your verification number builds itself.

If you're not on a tool yet, start in a spreadsheet — 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 before you draw the fish.

Copy this and run one this week

Take your top downtime cause from last week's Pareto, draw the six bones on a whiteboard, and fill them with the people who run the machine. Circle the two or three suspects you can test with data, confirm them at the machine, and run a 5 Whys on the winner. Write the corrective action with an owner and a due date, set the before/after number, and check it in two weeks. One tangled problem untangled and verified beats ten more guesses at the same recurring stop.

Latest articles

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.
The 5 Whys template for chronic downtime (with a worked example) — A copyable 5 Whys root cause analysis template plus a worked stamping-line example that chases a recurring stop to its real cause and corrective action.
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.