How to Track Machine Downtime When Half Your Stops Never Reach the Log Sheet

Machine downtime tracking is the record of every stop on a machine: when it started, how long it lasted, and the reason behind it. Deloitte estimates that unplanned downtime costs industry around $50 billion each year, and notes that weak maintenance practice can cut a plant's productive capacity by 5% to 20%.

Most plants do keep a log sheet. The problem is what the log sheet quietly leaves out.

• Can you tell your MD, without ringing the supervisor, exactly why Line 2 lost ninety minutes on Saturday's second shift?
• When an operator writes "machine problem" at 10 PM, how much of that entry is measurement and how much is memory?
• If your OEM asks for last quarter's MTTR on one specific press, how many days would it take to put that number together?

India's auto component industry crossed Rs 6.73 lakh crore in FY25, growing 9.6%, and the sector directly employs over 1.5 million people. Growth of that shape lands on the shop floor as tighter schedules on the same machines. This guide covers how to track machine downtime so the number survives an OEM question and an audit.

What Is Machine Downtime Tracking, and What Counts as a Stop?

Machine downtime tracking is the practice of recording every interruption to production on a machine, along with its duration and cause. It turns an idle machine into a dated, coded event that can be counted and compared later.

The definition sounds simple. The disagreement inside most plants is over what counts as a stop.

Here is the split that matters, and it is the one auditors and OEMs expect you to hold:

The line between planned and unplanned is where most log sheets get soft. A tool change is planned. A tool change that took forty minutes because the insert was not in the crib is not, and coding it as planned buries a real supply problem inside a routine bucket.

Once the categories are agreed, the next decision is how the stop gets recorded in the first place, and that choice sets the ceiling on everything after it.

Choose a Tracking Method: Manual, Automated or Hybrid

The method you pick decides how much of your downtime you will ever see. Every plant sits in one of three places, and moving up one level usually matters more than any analysis technique.

Compare them on the things that actually break:

Why hybrid wins for most auto component plants

The machine knows when it stopped. Only the operator knows why. Hybrid setups let the signal fix the clock and let the operator answer one question on a screen at the machine.

This is the approach we build most often for plants across Chakan and Ranjangaon, because it removes the argument about accuracy without adding paperwork to the operator's shift. It also fits older machines, since a simple contact or current sensor works where an OPC connection does not.

The trap in going sensor-only

A sensor-only rollout produces good-looking availability numbers and no ability to act. You learn the machine stopped 47 times last week and nothing about which 47 problems to fix.

With the recording method settled, the next question is what to measure, and this is where most plants track one number when they need three.

Record the Core Downtime Metrics Every Plant Head Should Hold

Total downtime alone tells you the size of the loss. It does not tell you the shape of it, and the shape is what decides where the money goes.

Three metrics do the work. ISO 22400-2, the international standard for manufacturing KPIs, defines these so two plants working from the same facts reach the same number.

Read them together and they point at different budgets. A falling MTBF means the asset is degrading and belongs in your preventive maintenance plan. A rising MTTR usually means spares, skills or response, not the machine at all.

Build a Reason Code Tree Your Operators Will Actually Use

A reason code is the short, fixed label an operator attaches to a stop. It is the single element that decides whether your downtime data can be analysed or only counted.

Most code lists fail for the same reason. They are written by the quality team, they run to fifty entries, and the operator picks the first one on the screen every time.

The rule that fixes it: six codes at the top level, three to five underneath each.

Here is a tree built for an Indian machining or forging shop, including two categories the standard templates leave out:

–   CNC alarm or fault

–   Hydraulic or coolant issue

–   Spindle or axis problem

–   Breakdown awaiting maintenance

–   Insert or tool change to standard

–   Tool breakage

–   Tool not available in crib

–   Setting and first-piece approval wait

–   Material short from stores

–   Wrong material or wrong batch issued

–   Rework or reject rerun

–   No operator at machine

–   Operator on break beyond schedule

–   Skill not available for that setting

–   Gauge or CMM wait

–   Inspection hold

–   Line rejection investigation

–   Power dip or supply failure

–   DG changeover time

–   Compressed air pressure drop

–   Customer schedule change

Those two bold entries are the ones imported templates never carry, and in the Pune belt they routinely account for a real share of lost minutes. Coding them separately is the only way to build a business case for a stabiliser or a faster changeover.

When we set up a code tree with a plant, we sit with the shift in-charge and the two most experienced operators before writing a single code, because the words on the screen have to match the words used on the floor. That is also why we keep the list on one screen with no scrolling. A code an operator has to hunt for is a code that never gets picked.

With clean codes flowing in, the analysis stops being guesswork and starts being arithmetic.

How to Analyze Stoppages and Cut Them Down

Analysis is where downtime tracking pays for itself. The sequence below takes a week of coded data and turns it into one funded action, and it works whether your data comes from a screen or a spreadsheet.

The key steps involved are:

Notice what the chart argues. The top reason on this cell is not a machine problem at all, it is a stores problem, and no amount of maintenance spend would have touched it. That is the value of coded data over a general sense that "the machines keep stopping".

The obvious next question is whether your current log sheet could have produced this chart, and there is a quick way to find out.

The 10-Minute Blind Spot Test for Your Current Log Sheet

Before buying anything, score what you already have. Pull last week's log sheet for one machine and answer six questions. Two points for yes, one for partly, zero for no.

How to read your score:

• 0 to 4, Blind. Your downtime number is an estimate. Any improvement claim built on it is unprovable.
• 5 to 8, Partial. You see the big breakdowns and miss the pattern. This is where most Tier-2 plants sit.
• 9 to 12, Reliable. Your data can carry a Pareto, a business case and an audit.

Most plants we meet score between four and seven, and question 2 is almost always a zero. That single gap is why the plant's own downtime figure and the OEM's delivery complaint never seem to line up. Fixing question 2 alone usually changes the shape of the Pareto completely.

What an IATF 16949 Auditor Asks to See

This is the part of machine downtime tracking that most guides skip, and it is the part that gets budget approved. Downtime data is not only an operations asset. It is audit evidence.

IATF 16949 clause 8.5.1.5, Total Productive Maintenance, asks for a documented maintenance system with documented maintenance objectives, giving OEE, MTBF and MTTR as examples. You cannot produce any of those three without stop-level records underneath them.

The last row is the one that decides the finding. An auditor can tell the difference between a record made at the machine and a sheet filled in afterwards, and so can an OEM quality team during a supplier assessment.

This is also why we link downtime records to the same management dashboards the MD already opens for output and rejection. When the audit question comes, nobody goes hunting through files.

Why Should You Choose Edhaas Digisoft for Machine Downtime Tracking?

Tracking machine downtime fails on the shop floor, not in the software. The operator has thirty seconds, the machine is old, and the code list has to match how your shift in-charge already speaks. We map that first, then build.

How we work on this:

• We map your current log sheet and reason vocabulary before writing any code, so the screen matches the floor.
• Signal-based stop detection on existing machines, paired with a one-tap reason screen for the operator.
• Modular rollout that starts on one cell, priced for an MSME, not a plant-wide programme.

What it has produced:

• Production log sheet automation: 40% improvement in production cycle time, with zero delays in reporting and compliance.
• Record integrity: audit-ready documentation with no missing records, so a disputed batch was verified in minutes.

We are founder-led and hands on, based in Pune and working across the auto component belt. Our production management and production dashboard work is built the same way: around your process, never a template.

Want to see which of your stops are currently invisible? Schedule a Consultation

Conclusion

Knowing how to track machine downtime comes down to three habits: record every stop with a real timestamp, attach a coded reason the operator can pick in one tap, and read MTBF and MTTR together rather than watching total downtime alone. Do that on one cell and the Pareto will usually point somewhere you were not spending money.

The return shows up in four places. Availability you can prove instead of estimate. PM frequencies set by failure history rather than habit. An answer ready when the OEM asks about a delivery miss. And clause 8.5.1.5 evidence that already exists on the day the auditor walks in.