A production downtime report example, daily and weekly

Most downtime "reports" are a spreadsheet tab nobody opens. The data is in there, but it is a wall of timestamps and free-text notes, and by the time you have filtered and pivoted it the production meeting is over. A useful report is the opposite: a short, repeatable page that answers four questions at a glance and points at one thing to fix. This article shows you exactly what that looks like, with a worked daily report and a weekly rollup from a single CNC machining cell.

If you are still deciding what to capture at the machine, read how to track machine downtime first — a report is only as good as the log underneath it. This piece assumes you already have clean events and want to turn them into something a plant manager will act on.

The four numbers a downtime report has to answer

Before any table, decide what the reader needs. A production downtime report exists to answer four questions, in this order:

Everything else — event counts, per-event duration, shift breakdowns — is supporting detail. If your report answers those four questions in the first few lines, it is already more useful than most. If it buries them under raw rows, it will not get read.

How much did we lose? Total downtime in minutes and hours for the period.
How available was the machine? Downtime as a share of scheduled run time, expressed as availability.
Where did the time go? The reason codes ranked by lost minutes.
Was it planned or unplanned? The split between activities you scheduled (setups, changeovers) and losses you did not (breakdowns, material waits).

A daily downtime report example

A daily report is a snapshot for the morning stand-up. Keep it to one machine and one day, and lead with the summary line. Here is Tuesday on a CNC machining cell scheduled for 450 minutes (one 7.5-hour shift after breaks):

That is the whole report. A supervisor reads it in ten seconds: the cell ran well, downtime was mostly planned setup work, and the only unplanned loss worth a note is the 20-minute material wait. No investigation needed today — just flag the material wait if it repeats.

The discipline is to resist adding more. A daily report is not a database dump; it is a signal. The moment it needs scrolling, people stop reading it.

Total downtime: 80 min (1.3 hours)
Availability: 82.2% (370 of 450 scheduled minutes running)
Top reason: setup / tool change (35 min)
Planned vs unplanned: 50 min planned / 30 min unplanned

A weekly downtime report example

The weekly report is where you actually find problems. Aggregate every event over five days, rank by minutes, and add a cumulative column so you can see the vital few. Same cell, one shift a day, 2,250 scheduled minutes for the week:

Now the report earns its keep. Run your finger down the cumulative column to 80%: it crosses at program / first article (81.1%). So four codes — setup, waiting for material, unplanned breakdown, and program setup — drive 81% of the week's lost time. The bottom three combined are under a fifth. That ranking is a full downtime Pareto analysis in table form, and it is the single most useful thing on the page.

Total downtime: 580 min (9.7 hours)
Availability: 74.2% (1,670 of 2,250 scheduled minutes running)
Top reason: setup / tool change (185 min, 32% of downtime)
Planned vs unplanned: 255 min planned (44%) / 325 min unplanned (56%)

How to read the weekly report

The numbers only matter if the reader draws the right conclusion. Here is how to interpret this week:

Notice what the report does not do: it does not tell you the cell is "bad" because availability is 74%. On a high-mix cell with eleven setups a week, a lot of that downtime is the business running normally. The report's job is to separate the downtime you chose from the downtime that chose you.

Setup is the top bar, but it is planned. Eleven setups for 185 minutes is 17 minutes each. That is not a breakdown — it is changeover work, and the lever is faster setups, not more maintenance. If that bar stays on top month after month, it is a signal to run a changeover study, not to chase reliability.
Waiting for material is the biggest unplanned loss. Six material waits for 120 minutes is pure external drag — the machine is fine, the parts are not there. This is usually a scheduling or staging problem upstream of the cell, and it is often the fastest win because it costs nothing to fix but coordination.
The unplanned breakdown is small but worth watching. Three events, 95 minutes, 32 minutes each. It is only 16% of the week, so a minutes-only read tempts you to skip it. Do not — three unplanned stops is a reliability signal, and per-event severity is a different problem than total volume.
The planned/unplanned split is the health check. This week is 44% planned, 56% unplanned. As you eliminate unplanned losses, the planned share rises, and that ratio is a useful trend as long as you also watch total minutes — a cell that simply adds more changeovers looks healthier by this measure without being so. Unplanned loss is the expensive, disruptive kind, and watching it shrink is more useful than any single week's total.

Layout rules that keep a report read

A report that nobody reads is worth nothing, no matter how accurate. A few rules that make the difference:

Lead with the four numbers. Summary first, table second. The reader should get the headline before they decide whether to read the detail.
Rank by minutes, always. A report sorted alphabetically or by code number hides the point. The top of the table should be the biggest loss.
Keep reason codes to a fixed list. If tool change, toolchange, and tooling are three rows, your ranking is fiction. Build a clean reason code list and aggregate on it.
Show planned and unplanned separately. Collapsing them hides the one distinction that changes what you do about the number.
Make it a series, not a one-off. The weekly report's whole value is watching the top bar shrink after you act on it. One report is a photo; a run of them is the movie.

Where the data comes from

Every number above assumes something unglamorous: that each stop got logged against a reason code at the machine, with a real start and end time. That is the hard part. Pull the log together by hand in a spreadsheet and you rebuild the pivot every week, clean up the free-text codes every time, and the report arrives a day late.

This is where HelpFab helps. In HelpFab's downtime tracking, operators log each stop against the machine from a phone or tablet by tapping one of your own issue types, so the codes are consistent before anything is charted. Each type carries a planned-downtime flag, so the split above comes for free. Issue reports rank your downtime by lost minutes and by event count over any date range and show the trend over time, which is the daily snapshot and weekly rollup above without rebuilding a pivot table. Each machine's page adds availability against its scheduled hours, and when a stop needs a fix, the issue type can raise a maintenance request on the spot, so the top reason code becomes an assigned job rather than another row.

The tooling matters less than the habit, though. Decide your four numbers, fix your reason codes, and publish the same short report every week. A plant manager who sees the same page every Monday and watches the top bar move will do more with a plain table than anyone will ever do with a dashboard nobody opens.

Latest articles

MTTR and MTBF: how to track them from your downtime log — Track MTTR and MTBF from your downtime and maintenance logs - the formulas, a worked quarter on one machine, and the mistakes that corrupt both numbers.
Maintenance log vs downtime log — Maintenance log vs downtime log - what each one captures, why a plant needs both, and how a single breakdown links them to give you MTTR and MTBF.
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.