Maintenance log vs downtime log

Ask two people on the same shop floor to "pull up the machine history" and you often get two completely different files. The maintenance tech opens a maintenance log — dates, repairs, parts, PMs. The production supervisor opens a downtime log — stops, reason codes, minutes lost. Both are looking at the same press, and both are right. They are just answering different questions.

The confusion costs you when someone decides one log is redundant and stops keeping it. It is not. A maintenance log and a downtime log capture different events, are kept by different people, and feed different metrics. The two overlap at exactly one point — the breakdown — and that overlap is where the most useful reliability numbers come from. This article walks through what each log is for, why you need both, and how to connect them without double-entry.

What a downtime log captures

A downtime log is a production record. It answers one question: why is the line not running right now? Every stop over a threshold — five minutes is a common cutoff — gets an entry: the machine, a start and end time, a reason code, and usually a short note.

The defining trait of a downtime log is that it captures every stop, not just the ones a mechanic touches. Waiting on material, waiting on a quality sign-off, a changeover that ran long, an operator break that overlapped a run — none of those are maintenance events, but every one of them is downtime. If your log only contains breakdowns, it is not a downtime log; it is a very incomplete repair history.

Because it captures everything, the downtime log is the honest ranking of where production time actually goes. It is what you Pareto to find the vital few causes, and it is what feeds the availability term in OEE. For the mechanics of setting one up — threshold, codes, who logs it — see how to track machine downtime, and for the code list itself see a practical machine downtime reason code list.

What a maintenance log captures

A maintenance log is an asset record. It answers a different question: what work have we done on this machine, and when? Each entry is a piece of maintenance activity — a preventive-maintenance task, a repair, an inspection, a part replacement — against a specific asset, with the date, who did it, the labor hours, and the parts consumed.

The key difference is the trigger. A maintenance log entry is created whenever maintenance happens, whether or not the line was down. A lubrication PM done during a planned weekend shutdown produces a maintenance record and zero downtime. A quick filter swap between jobs might never cross your downtime threshold but still belongs in the asset history. Conversely, a two-hour wait for material produces a big downtime entry and no maintenance record at all.

So the two logs are not subsets of each other. They intersect, but each contains a large region the other never sees:

Downtime only: waiting on material, changeover overrun, quality hold, no operator. Production lost, no maintenance done.
Both: a breakdown. The line stopped and a tech did repair work.
Maintenance only: PM during planned shutdown, off-line rebuilds, inspections that find nothing. Maintenance done, no production lost.

Why you need both

It is tempting to keep only one, usually whichever the loudest department owns. That always leaves a blind spot.

Keep only the downtime log and you can rank your problems but you cannot measure your response to them. You will know the press cost you 14 hours last month, but not how many times it broke, how long each repair took, or whether the PM you added in July is actually working. None of the reliability metrics — mean time between failures (MTBF), mean time to repair (MTTR), PM compliance, maintenance cost per asset — can be computed from a downtime log alone.

Keep only the maintenance log and you can see every repair but you have lost the production context. You will know the tech replaced a sensor three times this quarter, but not that each failure stopped the line for 90 minutes, nor that "waiting on material" quietly cost you more total hours than every breakdown combined. The maintenance log has no opinion about the stops that were never a maintenance problem, and those are often the biggest bars on the Pareto.

Put simply: the downtime log tells you where the pain is, across all causes. The maintenance log tells you what you did about the mechanical ones and whether it worked. You need the first to prioritize and the second to improve.

How the two logs connect

The connection point is the breakdown — the one event that lands in both logs at once. When a machine fails, the operator logs a downtime event (stop time, reason code, duration) and the tech logs a maintenance record (repair work, parts, labor). If those two records share the same machine and roughly the same timestamp, you can link them, and the link is where the best metrics live.

MTTR is the clearest example, because it is genuinely a sum of both logs. The clock has two parts: the time from the stop until a tech starts work, and the time the repair itself takes. The first part lives in the downtime log; the second lives in the maintenance log. Only together do they give you true mean time to repair.

Here is a worked example. Take one stamping press over a four-week window. Below are the four breakdown events as they appear in each log, matched by machine and time.

From this matched view you can compute the numbers neither log produces alone:

Notice what the breakdown rows leave out. That same month, the press also lost 6 hours to "waiting on material" and 3 hours to a long changeover. Those never touch the maintenance log, but they sit right at the top of the downtime Pareto — and they would be invisible if you only kept repair records.

MTBF: across roughly 460 scheduled run hours, 4 failures gives a mean time between failures of about 115 run hours. That rate comes from counting failures (downtime log) against uptime (production schedule).
MTTR: total down time of 325 minutes over 4 failures is about 81 minutes per failure. But split it: 110 minutes of that was waiting for a tech (downtime log) and 215 minutes was wrenching (maintenance log). Mean response time is 28 minutes; mean repair time is 54 minutes.
Where to aim: the Week 3 air-clutch rebuild dominates repair time, and the waits are a meaningful third of total down time. Those are two different fixes — a PM interval for the clutch, a faster escalation path for the wait — and you can only see both because you matched the logs.

Common mistakes

Treating the downtime log as a repair history. If operators only log stops when a tech shows up, you lose every non-maintenance cause — and those are usually the biggest. Log every stop, then flag which ones were maintenance.
Treating the maintenance log as a downtime record. A PM during planned shutdown is real maintenance and zero downtime. Rolling the two together inflates your apparent downtime and corrupts availability.
No shared key. If the downtime entry and the repair record do not share a machine ID and a timestamp, you cannot match them, and MTTR and MTBF stay out of reach. Decide up front how a breakdown links across the two.
Double-entry fatigue. When logging a breakdown means typing it twice, one of the two logs quietly dies. The fix is a system where the operator's stop and the tech's work order reference the same machine, so the link is automatic instead of a copy-paste.

Where HelpFab fits

HelpFab keeps both logs against the same asset so the link between them is built in rather than reconstructed later. Operators log each stop from a phone or tablet in Issues and downtime tracking, using your own configurable reason codes, which keeps the downtime log complete across every cause — maintenance or not — and feeds the Downtime Pareto view on the Issue Reports page. The Maintenance module holds the asset side: preventive-maintenance schedules with reminders and machine fix logs for the repairs themselves. Because a stop and the repair that follows both hang off the same machine, the breakdown that appears in both logs is one linked event instead of two disconnected rows — which is exactly what you need to get MTTR and MTBF without double-entry.

Whatever you use to hold them, keep both logs and share a key between them. The downtime log ranks every cause of lost production; the maintenance log records what you did about the mechanical ones. Keep only one and you are either prioritizing blind or improving blind.

Latest articles

Choosing a downtime tracking app for a small manufacturer — What a small shop should look for in a downtime tracking app: phone logging, configurable reason codes, and reports you can read without an ERP.
How to reduce unplanned downtime in manufacturing — A track-first playbook to reduce unplanned downtime - log every stop, Pareto the causes, then attack the vital few with PM and root-cause fixes.
How to calculate the cost of unplanned downtime — A cost-per-hour formula for unplanned downtime, with a worked molding-cell example covering labor, scrap, lost margin, and overhead.
A free downtime tracking Excel template (and how to actually use it) — A free Excel downtime log template — the columns, a reason-code list, and the pivot that turns raw stops into a Pareto, plus when to move off it.
OEE availability: how to calculate it from your downtime data — Calculate OEE availability from your downtime log, with a worked CNC example — plus the reclassification tricks that quietly inflate the number.
How to build a downtime Pareto analysis — Build a downtime Pareto step by step with a worked stamping-line example that finds the few causes driving most of your lost minutes.
A practical machine downtime reason code list — A starter taxonomy of machine downtime reason codes — planned vs unplanned, with real fault-code examples and rules that keep operators logging honestly.
Downtime tracking spreadsheet vs software — When an Excel downtime tracker is enough and when it quietly breaks — a shift-by-shift comparison for small manufacturers, with a real cost example.
How to track machine downtime — Move from a paper downtime log to structured tracking: reason codes, who logs what, and the three reports that actually change decisions.