Machine Downtime & Loss Log

What this tool does

CM8-87 is a downtime log that does the arithmetic you would otherwise do badly in a spreadsheet. You record each stoppage — when, which asset, why, how long, what it cost — and it produces the hours lost, the split between planned and unplanned, a Pareto of causes, a cost of lost production, and MTBF and MTTR per asset and across the site.

Everything runs inside this single file. There is no account, no upload and no network request, so your asset names, failure history and production values stay on the computer you are using.

What counts as downtime

Downtime is any time an asset that was supposed to be producing was not. That is wider than "it broke". The minutes field runs from the moment the asset stopped producing to the moment it was producing again — not from the moment maintenance arrived, and not to the moment the fault was signed off.

Three things are consistently under-recorded, and all three are usually worth more than the breakdowns:

• Short stops. A three-minute jam eight times a shift is half an hour, and nobody writes it down. Log them in a block if you must — "six stops on the infeed, 40 minutes total" — but log them.
• Reduced speed. The asset is running, so nothing gets recorded, yet you are losing output. Convert it to equivalent lost hours: if a machine ran four hours at 70 % of rate, that is roughly 1.2 hours of lost production. Record 72 minutes, and say so in the description.
• Waiting. No material, no operator, no forklift, no quality release. The asset was ready and did not run. That is downtime, and its cause is usually easier to fix than a bearing.

The categories

The eleven categories are a deliberately short list, because a Pareto over a free-text field is useless — the same cause gets typed five ways and the ranking dissolves. Put the category in the drop-down and the detail in the cause and description boxes.

Breakdown is the one that carries weight: it is the only category that counts as a failure for MTBF and MTTR by default. Use it when the asset failed and had to be repaired. If a tool broke and the asset stopped, that is a judgement call — log it as tooling if replacing the tool is routine, and as a breakdown if something failed that should not have.

No demand is worth a word of warning. Time with nothing scheduled to run is not a loss in the way a breakdown is; it is capacity you chose not to use. It is in the list so the day is fully accounted for, but if you are reporting a loss figure to anyone, filter it out first.

Planned against unplanned

Every stoppage is classed as planned or unplanned, and the split is the single most useful number in the log. Planned hours you chose to take at a time that suited you. Unplanned hours took themselves, usually at the worst moment, and cost far more per hour because of what they do to the schedule around them.

By default the class comes from the category. Setup and changeover, planned maintenance and no demand count as planned; everything else counts as unplanned. The Planned or unplanned field overrides it for the exceptions — a changeover forced on you by a customer, or a repair you had already scheduled into a window. Leave it on Auto the rest of the time.

A site with a healthy maintenance regime sees planned hours rise and unplanned hours fall. If both are falling, check that people have not simply stopped recording.

MTBF, and what it needs

Mean time between failures is the average running time you get out of an asset before it fails. It is not calculated from the log alone: it needs to know how long the asset was operating, and only you know that.

Set operating hours per asset in the period on the Settings tab. For a single asset the tool divides that figure by that asset's failures. For the site figure it multiplies by the number of assets appearing in the current filter, then divides by the total failures:

Four things will make this number wrong, and the tool cannot detect any of them:

• The hours do not match the filter. This is the common error. If you enter a year of operating hours and then filter the log to one quarter, you divide a quarter's failures into a year's hours and MTBF comes out four times too high. Change the filter, change the hours.
• Your assets run different schedules. The setting is one figure applied to every asset. If the oven runs one shift and the press runs three, filter to one asset at a time and set the hours for that asset.
• Assets with no downtime never appear. A machine that ran all quarter without stopping has no records, so it is not counted in the asset total. That understates the operating time and makes site MTBF lower than reality — conservative, but wrong.
• Too few failures. With two failures, one more or one fewer moves MTBF by half. The tool shows the figure but marks it as indicative until you pass the failure count set on the Settings tab.

If the operating hours are left at zero, MTBF shows a dash. That is deliberate. A dash tells you the figure is unknown; a number you have not earned tells you something false.

Planned maintenance is not a failure, and it is excluded by default. There is a setting to include it, for the rare case where you are tracking intervention rate rather than reliability — but understand what it does: the more preventive work you do, the worse your MTBF looks. Leave it off.

MTTR

Mean time to repair is the average length of a failure.

It uses the same set of events as MTBF, so the two figures always agree with each other. Note what this measures: time to restore, from the asset stopping to the asset producing again. That includes waiting for someone to notice, waiting for a technician, waiting for a part, waiting for a permit, and testing afterwards. Hands-on repair time is a fraction of it.

That is the honest and usually more useful figure, because the waiting is where the time actually goes. If you want to attack it, put the waiting in the description — "two hours waiting for an engineer, forty minutes repairing" — and the pattern will be obvious within a month. Do not shorten the recorded downtime to only the wrench time: it will flatter MTTR and hide the real problem.

MTBF and MTTR answer different questions. MTBF asks how often it fails; MTTR asks how bad it is when it does. An asset with a long MTBF and a long MTTR fails rarely but hurts badly, and usually needs spares held on site. An asset with a short MTBF and a short MTTR is a nuisance you can measure — and usually the cheaper one to fix.

Getting the operating hours right

Operating hours are the hours the asset was scheduled and available to run. Start from the shift pattern: a two-shift, five-day operation over thirteen weeks is roughly 16 × 5 × 13 = 1,040 hours. Deduct shutdown weeks and public holidays as they apply to you.

Two conventions exist and they give different answers. Some organisations divide by scheduled time as above; others subtract the downtime first to get true running time. The second is stricter and gives a lower MTBF. This tool uses the figure exactly as you type it — if you want the running-time basis, subtract the downtime hours the tool reports from your scheduled hours and enter the result. Say which basis you used whenever you quote the number, because the two are not comparable.

Reading the Pareto

The Pareto chart and table rank causes by hours lost, largest first, with a running cumulative percentage.

Read the cumulative column down until you pass about 80 %. The causes above that line are the ones worth a project. Everything below it is noise until the ones above are dealt with. This is the whole point of ranking by hours rather than by count: twenty short stops can look alarming in a count and be worth less than one long breakdown.

Cross-check the Pareto against the cost chart before you decide. They frequently disagree, because a cheap asset can be the bottleneck and an expensive repair can happen on a machine nobody was waiting for. Hours tell you where the time went; cost tells you what it was worth.

Costing the loss

Each record can carry the units of production lost and what one unit is worth. A default unit value on the Settings tab covers records where you do not set one.

Use contribution for the unit value — the selling price less the material and other costs you avoid by not making it — rather than the full selling price. Selling price overstates the loss substantially, and anyone in finance will say so.

Two further points about honesty. First, output you can catch up later, by running overtime or filling a gap in the schedule, is not lost — it is deferred, and it costs you the overtime rather than the margin. Second, the totals here exclude labour standing idle, scrap generated around the stoppage, expedited freight, and anything a late delivery does to a customer relationship. The figure is a floor, not a full cost of loss. It is most useful as a comparison between assets and causes, and as the business case for spending money on prevention.

What this tool will not tell you

It does not calculate OEE. Overall equipment effectiveness needs availability, performance and quality measured on a consistent time base, including good-parts counts this log does not hold. Downtime hours are one input to availability, not the whole of it.

It does not measure anything itself: there is no machine connection, no counter, no sensor. Everything here is what somebody typed. It cannot tell whether a stoppage was categorised correctly, whether the cause written down is the real one, or whether the stoppages that were never logged are the ones that matter.

It also cannot see the difference between an asset that is genuinely reliable and an asset nobody bothers to record. A machine with no entries looks perfect in every chart here.

Making the log survive contact with the shop floor

A downtime log fails for predictable reasons. It is worth designing against them.

• Set a threshold and publish it. Decide the shortest stoppage you will record — five minutes is common — and hold to it. An unstated threshold means every shift uses a different one and the trend is meaningless.
• Record at the time, not at the end of the week. Reconstructed durations are rounded to the nearest comfortable number and causes get invented.
• Never use the log to judge a shift or a person. The moment it does, reporting stops, the numbers improve, and you lose the only instrument you had.
• Fill in the cause, not just the category. The category tells you where to look; only the cause tells you what to change. "Bearing failed" is a symptom. "Greasing point behind a guard, missed on the last two visits" is something you can fix.
• Close the loop. Leave a record open until the action that stops it recurring is actually done. A log of resolved records with empty action fields is a log of stoppages that will happen again.

Printing and sharing

Print Report produces a report from whatever the current filter shows: header, the six headline figures, all four charts, the Pareto table, the asset summary, the full log and your closing notes. Print to PDF to circulate it.

The scope line under the title states the filter in force. Before issuing anything, check two things: that the filter describes the period you say it does, and that the operating hours on the Settings tab cover that same period. Those two disagreeing is the only way this tool will hand you a confidently wrong MTBF.

Saving your work

Records, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the log for spreadsheet work and includes every filtered record, not only those drawn on screen. Reset asks twice, then erases everything this tool has stored. There is no undo.

Accuracy & disclaimer

This tool calculates from what you enter and nothing else. MTBF and MTTR are only as sound as the operating hours, the failure classification and the completeness of the log — and a downtime log is almost never complete.

Reliability conventions differ between industries and between organisations, and so do the definitions of failure, of operating time and of downtime itself. Agree yours in writing before you publish a figure, and state the basis every time you quote one. This is an internal record-keeping and calculation aid, not a reliability engineering study, not a warranty or contractual measurement, and not a substitute for competent maintenance engineering judgement.