How to run a weekly downtime review that fixes causes

The weekly downtime report fits on one page with five blocks: stopped time against scheduled time, the reasons ranked by hours, the leading reason split by shift and machine, the open actions, and a check on earlier fixes. Fixes stick when the review takes one reason down to a cause someone can change, sets a numeric target before the change, and reads that reason for four weeks after.

This guide is for plant managers whose operators already put a reason on most stops. If yours don't yet, start with which reason codes to log.

What a downtime review is#

The report is the input and the meeting is the method. A chart emailed on Monday that nobody acts on changes nothing on the floor.

The trap the review exists to break is old. NASA's maintenance guide puts it plainly: when equipment fails repeatedly, maintenance personnel often fix only the symptoms and keep doing the same repairs.^[1] The same guide sets four goals for root cause analysis: find the cause quickly and economically, correct the cause and not only its effect, help prevent recurrence, and instill a mentality of "fix forever".^[1]

A weekly review applies those goals to production downtime, and it drives any plan to reduce machine downtime. For example, a plant that restarts a jammed infeed conveyor 20 times a week has a repair habit. The review asks why it jams.

What goes on the one-page report?#

The A3 report, a practice Toyota pioneered, puts the problem, the analysis, the corrective actions and the action plan on a single sheet of paper.^[4] The weekly downtime report is a lighter version of the same idea: five blocks, one page, read in order.

Three rules keep the page honest:

• Show the stopped share, not only hours. A four-day week shrinks hours with nothing improved. 40.0 stopped hours out of 480 scheduled is 8.3%, and that is the number to compare.
• Show unclassified time in the headline. If Unclassified is one of the top three bars, the Pareto ranks missing reasons. Fix classification before you read anything else.
• Keep the fix check on the page. Without block 5, the review keeps opening actions and never learns whether any worked.

A Pareto chart ranks reasons by the time they cost, with a cumulative line, see the glossary entry. To rank by money instead, price an hour first with the cost-of-downtime method.

Run the review in 30 minutes#

Hold the review at the same slot each week, Monday morning for the week before. Build the report before the meeting, so the 30 minutes go to decisions.

1. Check classification, 5 minutes

   Read the unclassified share. If it rose, find the shift or machine where the habit slipped and fix that first. Tracking every stop and its reason covers the daily check that prevents this.

2. Read open actions, 5 minutes

   Each owner gives one line: done, on track, or blocked and why. Blocked actions get a decision in the room, not next week.

3. Check fixes that are due, 10 minutes

   For each action whose four-week check window has closed, compare the reason before and after against its target. Close it, or reopen it with a new countermeasure.

4. Pick the next reason, 10 minutes

   Take the leading reason that has no open action. Assign one person to find its cause by next week, with a date.

Limit the work to two new reasons a week. NASA's guide ranks recurring problems with Pareto analysis, then matches them to the people and money available.^[1] Two actions that get finished return more running time than ten that stall.

Datwyler's injection molding plant in Ontario, California, runs this pattern on more than 20 machines: it reviews the Downtimes report week over week and month over month, with the reports emailed on a schedule. Week over week, the reports showed Tuesday shift transitions adding 8 to 10 minutes of downtime every week. Within six months the plant cut shift-changeover downtime by 50% and material-changeover downtime by 30%, as Datwyler's story describes.

By tracking downtime categorization week to week and month to month, we could see exactly where our biggest problems were and track whether our fixes actually worked. The 50% reduction in shift changeover time came directly from acting on patterns we saw in the historical reports. That's not luck; that's discipline meeting data.

Find the cause behind the reason#

A reason code records what the operator saw: Start of shift, Waiting for material, Changeover. It doesn't say why. The person who owns the reason has a week to get from the code to a cause.

Narrow the reason first#

Split the leading reason by machine, by shift and by day of the week before you ask why. Drilling into the leading Pareto bar works this through for a week of changeovers.

The split tells you what kind of cause to look for:

• Concentrated on one machine: look at that machine's condition, tooling or setup.
• Concentrated on one shift or day: look at staffing, handovers and schedules.
• Spread across every machine and shift: look at a shared method, policy or supply.

Then read the operator notes on the stops. Make notes required on vague codes such as Other, using the required-note setting on a downtime category. Then go to the machine at the time the stops happen and watch one.

Ask why until you can change something#

The Lean Enterprise Institute defines 5 Whys as asking why repeatedly whenever a problem is encountered, to get beyond the obvious symptoms to the root cause.^[2] Its example, from Taiichi Ohno, starts with a stopped machine and a blown fuse. It ends five answers later at a missing strainer that let metal scrap into a lubrication pump.^[2] Replacing the fuse would have fixed the symptom, and the machine would have stopped again.

The number five isn't the rule; the stopping point is.^[2] Stop when the answer is something a person can change: a method, a schedule, a design, a setting or a supply.

NASA's guide groups failure causes into general categories for further analysis: machinery, people, methods, materials, policies, environment and measurement error.^[1] Use the list as a prompt when a why-chain stalls.

Write the countermeasure with a target#

NASA's process asks for the expected improvement in performance when a problem is assigned, as the standard by which to measure possible solutions.^[1] Write that number down before anything changes. Without it, any drop looks like success.

Derive the target from the cause where you can. In the lathe example, moving the handover removes its 10 minutes and leaves the sequential checks: 2 × 3.5 = 7.0 minutes per start. That's the target.

Separate containment from the fix. Containment limits the loss this week, such as a lead operator checking first parts while the inspector is in the handover.

The countermeasure removes the cause. Log both, and close the action only on the countermeasure.

When the cause is equipment, the countermeasure is maintenance work. Open the work order from the stop itself, so it carries the machine, the reason and the operator's note: see creating a work order from a stop.

Check that the fix held#

The PDCA cycle calls this step Check: evaluate the results against the targets. Then Act: standardize the change, or begin the cycle again.^[3] Most reviews skip Check. The fix check block exists so they can't.

Use four rules:

1. Compare equal windows. Four weeks before against four weeks after. One good week proves nothing.
2. Normalize the reason. Divide by shift starts, changeovers or scheduled hours, so a short week doesn't flatter the result.
3. Compare against the target written before the change. Not against whatever the after-number turns out to be.
4. Check the neighbors. If Start of shift falls and Waiting for inspection rises by the same minutes, the loss moved codes. Nothing was fixed.

Act on the result. A met target becomes the standard: update the shift schedule and the handover procedure, so the next quality lead inherits the fix.

A missed target reopens the action with the next why. Either way, the reason stays in the fix check block for one more month, to catch drift.

Build the report automatically#

IoTFlows detects every stop from a sensor on the machine, and operators put a reason on it in a tap. The Downtimes report ranks the reasons by hours and splits them by interval and by machine, with filters for shift, category and notes, which covers blocks 2 and 3.

Set the report to Last 7 days and schedule it to email weekly, so every attendee has the same page on Monday morning. Download the PDF for the meeting, or the CSV, one row per stop, when you build the before-and-after fix check. See available exports.

See how downtime tracking works from the sensor to the report.

Start the review this week#

1. Pick a fixed 30-minute slot and name who attends.
2. Build the five-block report for last week, and check that unclassified time is small.
3. Pick the leading reason, split it by machine, shift and day, and assign one owner to find its cause.
4. Write the countermeasure with an owner, a due date and a numeric target before anything changes.
5. Four weeks after each change, run the fix check per shift start or per scheduled hour, and standardize or reopen.