What machine downtime tracking is
Machine downtime tracking is the practice of recording every time an asset stops producing — the moment it goes down and the moment it is restored — so that downtime duration is captured automatically instead of estimated after the fact. In a CMMS, this lives on the breakdown ticket: each ticket carries a downtime clock with a time-down (start) and a time-restored (stop) timestamp, and the difference between them is the downtime — no arithmetic, no arguing.
Once that data exists on every stoppage, it becomes the raw material for everything else maintenance wants to know: which machine lost the most hours this month, which line is the bottleneck, which fault keeps coming back, and whether response is getting faster. Those same timestamps also feed the reliability KPIs — MTTR and availability — with no separate tally. Downtime tracking, in other words, is the single input that most of maintenance measurement depends on.
Why paper breakdown registers fail
Many Indian plants still keep a paper breakdown register at the shop floor — a bound book where the operator or fitter scribbles what stopped and, sometimes, roughly when. It feels like a record. In practice it fails at exactly the three things downtime data is supposed to do.
1. No reliable timestamps
A register entry usually says "morning shift" or "approx 2 hrs," written from memory once the machine is back and the pressure is off. Nobody stood there with a watch. Without a real time-down and time-restored, the duration is a guess — and guesses cannot be summed into an honest monthly downtime figure.
2. Nobody analyses it
Even where the book is filled in diligently, it is a book. To find out which asset failed most, someone would have to leaf back through weeks of handwriting and tally it by hand — so nobody does. The data goes in and never comes out. A register you cannot sort, filter or chart is a diary, not a dataset.
3. Decisions are made on gut feel
With no analysable history, the maintenance head decides where to spend preventive effort on instinct and on whichever breakdown shouted loudest last week. That is how a plant ends up over-servicing a reliable machine while the actual top-failing asset quietly keeps eating hours.
What to capture on every downtime event
Good downtime tracking is not about capturing more — it is about capturing the same few fields on every event, so the data is comparable. These are the fields worth insisting on for each stoppage:
| Field | What it records | Why it matters |
|---|---|---|
| Asset | The exact machine, from the asset register | Lets you total downtime and failures per machine |
| Time down | Timestamp the machine stopped | Starts the downtime clock — the source of truth |
| Time restored | Timestamp it ran again | Stops the clock; duration is the difference |
| Downtime duration | Restored minus down, computed | The headline number — automatic, not typed |
| Planned / unplanned | Scheduled work vs breakdown | Separates necessary maintenance from failures |
| Cause category | Fault type — mechanical, electrical, etc. | Enables Pareto analysis of what drives losses |
| Action taken | What was done to restore it | Builds the repair history for the asset |
| Spares used | Parts issued against the repair | Links downtime to spare consumption and cost |
| Technician | Who attended and repaired | Accountability and response-time analysis |
The discipline that makes this pay off is the cause category being chosen from a consistent list rather than free-typed differently every time. When "bearing seized," "brg fail" and "bearing hot" are three different strings, no report can group them. Pick from a category, add a free-text remark for detail, and the analysis in the next sections becomes possible.
Planned vs unplanned downtime
Not all downtime is a problem. Planned downtime is stoppage you chose — preventive maintenance in a set window, a changeover, a trial, a scheduled clean. It is the cost of keeping the asset healthy, and you want it visible but you do not want to confuse it with failure. Unplanned downtime is the breakdown: the machine stopped without warning, mid-run, and took production with it. That is the expensive kind, and it is the number you are really trying to shrink.
Tagging every event as planned or unplanned is what lets you separate the two. It also connects to a wider idea: in the language of OEE and the classic six big losses, downtime splits into breakdown losses and setup-and-adjustment losses — the availability side of overall equipment effectiveness. You do not need a full OEE programme to benefit. Simply distinguishing breakdowns from changeovers already tells you whether your lost hours come from machines failing or from how the line is run — and downtime tracking on breakdown tickets is the availability half of that picture, the half most plants can fix first.
The downtime clock on a breakdown ticket — start to stop
Here is the sequence the downtime clock runs through, from the moment a machine stops to the moment its lost hours land on a dashboard.
The point of the two-timestamp design is that nobody has to calculate anything. The operator or fitter records when it stopped and when it started again; the software owns the subtraction — removing both the arithmetic errors and the temptation to round a two-hour outage down to "about an hour." For serious or recurring failures, the ticket also opens into the platform's root-cause and 8D machinery, so a repeat fault gets a structured investigation rather than another one-line remark.
Analysing downtime — by asset, by line, by cause, by period
Captured consistently, downtime can be sliced four ways, and each slice answers a different management question.
| Cut | The question it answers | What you do with it |
|---|---|---|
| By asset | Which machine loses the most hours? | Target the top-failing asset for preventive work |
| By line / area | Where is the bottleneck concentrated? | Prioritise the line that constrains output |
| By cause (Pareto) | Which faults drive most of the loss? | Fix the vital few causes, not the trivial many |
| By period | Is downtime trending up or down? | Prove whether interventions are working |
The by-cause Pareto is usually the most revealing. Sort causes by total downtime hours and, more often than not, a handful of fault categories account for the large majority of lost time. That is where preventive effort and spares budget should go first. Dhruv AI can go a step further and cluster the free-text breakdown-cause remarks into named recurring themes, so patterns that hide across slightly different wordings — "seal leak," "oil seepage," "gasket weep" — surface as one theme worth attacking.
And because the analysis runs off the same time-down and time-restored stamps, it feeds the reliability KPIs for free. Total repair time divided by the number of failures is MTTR; the uptime between failures is MTBF; and availability is MTBF ÷ (MTBF + MTTR). Every closed breakdown ticket updates all three, machine by machine — see MTTR, MTBF and availability explained and Dashboards & MTTR/MTBF.
The cost of downtime in INR — a worked example
Downtime hours become a lever the moment you put a rupee figure on them. The arithmetic is simple: downtime hours × cost per hour. The cost per hour is your own number — it should include lost contribution margin on the output you did not make, idle operator wages, and any expedited-spare or overtime premium. Take an indicative rate to see the shape of it.
What one top-failing machine costs in a month
Say a packing line loses 40 hours of unplanned downtime in a month, and you cost that line at an indicative ₹8,000 per hour of lost production. That is 40 × ₹8,000 = ₹3,20,000 in a single month from one asset — roughly ₹38 lakh a year if the pattern holds. Now suppose downtime analysis shows a repeating air-cylinder fault drives half those hours, and a preventive change plus a spare on the shelf removes it. Halving the loss saves about ₹1,60,000 a month — the kind of number that pays for the fix, and the system, many times over. (Rate and hours are indicative, to show the method — plug in your own.)
The exact figures matter less than the habit: once every stoppage carries a duration, and duration carries a rupee rate, downtime stops being a maintenance grumble and becomes a line on which the plant manager can see the return on a preventive schedule or a spare-parts investment.
From data to action: fixing the top-failing asset
Analysis only earns its keep when it changes what you do. The path from a downtime dashboard to fewer lost hours is short and repeatable, and it almost always starts at the same place: the asset at the top of the by-asset chart.
- Rank assets by total downtime and take the top one — the single machine eating the most hours.
- Run a cause Pareto on that asset alone to find the one or two faults behind most of its downtime.
- Add a targeted preventive maintenance task that pre-empts that fault, on a schedule that fits how the machine is run.
- Stock the spare that fault consumes, with a reorder level, so the fix is never held up for a part — see spare parts inventory management.
- For serious or recurring failures, run a root-cause / 8D investigation so the fault is removed, not just repaired again.
- Watch the by-period trend for that asset to confirm the intervention actually moved the number.
This is also the through-line between reactive and planned work: downtime data is what tells you which breakdowns to convert into preventive tasks. For the broader playbook, see how to reduce machine downtime and preventive vs breakdown maintenance.
Still logging breakdowns in a register nobody adds up?
We can show you a breakdown ticket with a live downtime clock, a downtime-by-asset Pareto, and an MTTR/availability dashboard in 30 minutes — on your own machines.
How Fast Maintenance Software implements downtime tracking
Fast Maintenance Software, built by Improsys in Pune on the shared Fast Suite platform and available cloud or on-premise, implements everything above as working screens rather than intentions:
The result is the India moat in one line: the paper breakdown register that nobody analyses is replaced by a timestamped ticket that everybody can — so lost hours become a number you manage, not a story you tell after the shift.
Frequently asked questions
What is machine downtime tracking?
Machine downtime tracking is the practice of recording every time an asset stops — the moment it goes down and the moment it is restored — so downtime duration is captured automatically rather than guessed. In a CMMS, each breakdown ticket carries a downtime clock, and those timestamps feed downtime analysis by asset, line and cause, plus MTTR and availability KPIs.
How do you track machine downtime accurately?
You track downtime accurately by logging two timestamps on every breakdown ticket: time-down when the machine stops and time-restored when it runs again. The system subtracts one from the other to give downtime duration, so nothing depends on memory. You also record the cause, action taken, spares used and technician, which turns each stoppage into analysable data.
What is the difference between planned and unplanned downtime?
Planned downtime is stoppage you schedule — preventive maintenance, changeovers or trials — done in a chosen window. Unplanned downtime is a breakdown that stops production without warning, and it is the expensive kind. Tracking both, and tagging each event as planned or unplanned, lets you separate necessary maintenance from the failures you actually need to attack.
How does downtime data feed MTTR and availability?
The time-down and time-restored timestamps on breakdown tickets give both the number of failures and the total repair time, which is all MTTR and availability need. MTTR is repair time divided by failures; availability is MTBF divided by MTBF plus MTTR. Because the clock runs on every ticket, these KPIs are computed automatically, with no separate tally.
How do you analyse and reduce machine downtime?
You analyse downtime by asset, line, cause and period — a Pareto of causes usually shows a few faults driving most lost hours. Dhruv AI can cluster breakdown-cause remarks into named recurring themes. You then reduce it by fixing the top-failing asset: a targeted preventive schedule, the right spares on the shelf, and root-cause action on repeat faults.