Equipment Downtime Analysis: A Step-by-Step Method

Equipment downtime analysis means finding out which stops cost you the most time, why they happen, and whether your fix worked.

It is not a report. It is a weekly habit that moves the biggest losses down the list.

In this article, downtime means any scheduled time a line is not making product, planned or unplanned.

Below is the method in 7 steps, with one worked example. All numbers in the example are made up to show the maths.

The 7 steps at a glance

1. Capture every stop with a start, an end and a reason.
2. Classify each stop: planned or unplanned, availability or performance loss.
3. Rank the stops with a Pareto, by time and by frequency.
4. Add MTBF and MTTR where failures matter.
5. Find the root cause of the top stops.
6. Set a countermeasure with an owner and a date.
7. Verify with the same data, then start the loop again.

Step 1: Capture every stop with a reason

You cannot analyse what you did not record. Each stop needs a start time, an end time, the machine or line, and a reason.

Add the product, the shift and a short comment. These make the later steps much easier.

Three rules from R.C. Hansen's OEE method help here:

• Account for every minute of scheduled time. Never allow a reason called "other" or "miscellaneous".
• Record how often a stop happens, not only how long it lasts.
• Check the log against a second source, such as a cycle counter or hour meter.

Paper sheets are fine to start. Over time, reasons get forgotten and times get rounded.

Machine data fixes the times. Operators then only pick the reason. See how this is done in our review of downtime tracking software.

Step 2: Classify each stop

Split the stops first into planned and unplanned. Then link each one to the OEE factor it reduces.

Every stop you log counts against availability. Slow running counts against performance. Bad units count against quality.

Very short stops are the exception. Many plants set a micro-stop threshold and count those in performance instead.

Keep one more bucket apart: excluded time. Hansen uses it for time that was never scheduled for production, such as a maintenance shutdown planned a week or more ahead.

Excluded time is not downtime. If you hide real losses in it, your analysis looks better than your plant.

Step 3: Rank the stops with a Pareto

A Pareto chart sorts stop reasons from largest to smallest and adds a running total. A few reasons usually carry most of the time.

Build it twice: once by total minutes, once by number of stops. They often point to different problems. Our guide on Pareto analysis of downtime covers the chart in detail.

Example: one line, one week, all stops except the planned changeover. That is 540 minutes with a reason, plus 60 unclassified.

Three reasons make up 80% of this time. That is where to look first.

Notice the two views. Film jams are 42 short stops of about 5 minutes. The motor failure is only 2 stops, but each one lasts about an hour.

These need different answers. Add Paretos by line, shift and product as well. A reason that looks small plant-wide can dominate one shift.

Step 4: Add MTBF and MTTR where failures matter

A Pareto tells you how much time was lost. MTBF and MTTR tell you if the loss comes from stops that are too frequent or restores that are too slow.

• MTBF (mean time between failures) = running time ÷ number of failures. It shows how often the machine stops.
• MTTR (mean time to restore) = unplanned stop time ÷ number of unplanned stops. It shows how long a stop lasts.

Define "restore" once and use it everywhere. Hansen counts it from the end of production to the start of the next production, so it includes calling, waiting for parts and start-up, not only the repair itself.

Some plants count only the hands-on repair. Hansen calls that repair time and keeps it apart from restore time.

Strictly, MTBF counts equipment failures only. For all unplanned stops, such as a jam caused by bad material, Hansen uses the same sum under the name MTBI.

Example: the line ran 1,500 minutes in the week.

• Motor failure: MTBF = 1,500 ÷ 2 = 750 min. MTTR = 120 ÷ 2 = 60 min. Rare but slow to restore, so look at spare parts, diagnosis and who gets called.
• Film jam (not an equipment failure, so the all-stops version): time between stops = 1,500 ÷ 42 = about 36 min. MTTR = 210 ÷ 42 = 5 min. Frequent but quick, so look for the cause that makes it jam.

Frequent stops call for prevention. Slow restores call for a faster response. Watch restore time over time as well: Hansen describes a plant where small stops took 1.1 minutes to restore instead of 0.8, and output fell 10% with no single big event to blame.

Step 5: Find the root cause

Take only the top 2 or 3 stops from the Pareto. Go and look at the machine, the log and the operator notes before the meeting.

5 Whys

Ask "why" until you reach something you can change. Usually that takes 3 to 5 questions.

Example for the film jam:

1. Why did the line stop? Film jammed at the sealer.
2. Why did it jam? The film edge was curled.
3. Why was it curled? The reels from one supplier lot are wound too tight.
4. Why did it reach the line? Incoming film is not checked against a width and tension spec.

The cause is a missing incoming check, not "operator error". If your answer ends with a person, ask one more why. Usually the cause sits in the process, not in the operator.

Fishbone (Ishikawa)

Use a fishbone when several causes may combine. Draw the stop as the head and group causes under 6 bones:

• Machine
• Method
• Material
• People
• Measurement
• Environment

Then use your data to cross out the ideas that do not fit. Keep the ones the log supports, for example "only the night shift" or "only product B".

Step 6: Set a countermeasure

A countermeasure is the action you take against a root cause. Lean practice calls it that because the next improvement will replace it.

Write it down with four things:

• What exactly will change.
• Who owns it.
• The date.
• The number that should move, such as "film jam stops per week".

Pick fixes that remove the cause. A faster restart helps, but a stop that never happens costs nothing.

Step 7: Verify and repeat

After the date, run the same Pareto on the new data. Did the minutes drop? Did the stops drop? Did another reason grow to fill the gap?

If the number did not move, the cause was wrong or the fix was too weak. Go back to step 5.

If it moved, update the standard, close the action and take the next reason from the list. This is a plan, do, check, act loop, run weekly.

Common mistakes

• An "other" reason. It hides the next big loss. Keep unclassified time visible and push it toward zero.
• Looking at minutes only. Many small stops are easy to miss in a time Pareto.
• Mixing planned and unplanned. Changeovers need their own work, not a repair mindset.
• Counting short stops differently each week. Set one threshold and keep it.
• Stopping at "operator error". That ends the learning. Ask why the process allowed it.
• No check afterwards. Without step 7, you only have a list of ideas.

How Fabrico supports downtime analysis

Fabrico is a light MES in the cloud. It records OEE and downtime from machine data (PLC, IoT sensor or camera) together with the reasons operators choose.

It covers the steps above like this:

• Capture: the line timeline shows running, stops and changeovers in colour. Stop time without a reason shows up as unclassified until someone adds the reason, so gaps stay visible.
• Classify: reasons are set up as planned or unplanned, and can be linked to specific machines.
• Rank: OEE analytics show the top unplanned and planned reasons, and a table of the top stoppages with downtime, frequency, share and average duration, split by line. You can cut it by hour, shift, day, week or month, and export it. Frequency and average duration answer the same question as step 4. MTBF and MTTR themselves are maintenance reports, not part of OEE analytics.
• Evidence: operator comments stay with each stop. Where cameras are installed, Fabrico can suggest a stop reason from the footage, and a person confirms it.
• Act and verify: a stop reason can also create a task automatically, which helps when the fix is a maintenance job. Compare the same analytics before and after your change.

Read more on Fabrico MES and OEE.

To see your own stops in a Pareto, Request a demo or Contact us.

What people ask next

How do I calculate the downtime percentage?

Downtime % = stop time ÷ scheduled time × 100. Here stop time means all stops, planned and unplanned. Example: 900 stop minutes in 2,400 scheduled minutes is 37.5%.

In this example, availability is the rest: 100% minus 37.5% is 62.5%. Excluded time stays out of both numbers.

How much data do I need before I start?

Start with one week. A first Pareto from a single week is already useful.

Hansen says three to six months of data is enough to work with. Keep the weekly review going as the data grows.

Should I analyse every machine?

No. Start at the bottleneck, the machine that limits the output of the line.

Time lost there is lost for the whole line. Time lost at a machine with spare capacity often costs far less.

What about very short stops?

Short stops add up, and they are the first thing paper logs miss. Pick a threshold, record them the same way every week and review their count as well as their time.

Our page on micro-stops explains how to handle them.

How do I put a cost on downtime?

Multiply lost minutes by what a minute is worth. That depends on whether you could have sold the output.

• If you could have sold it: lost units × margin per unit. Use the margin before fixed labour and overhead, or you count them twice.
• If you could not sell it, or can make it up later: count only the extra cost, such as overtime and scrap.

Example: a line that normally runs 600 units an hour at a €2 margin loses €1,200 of margin in one lost hour, but only if that output could have been sold. The free field guide Why lines stop shows how to price a stopped hour.

Ready to see your downtime this way? Request a demo or Contact us.