How do I calculate the cost of a downtime event?

Cost per event equals duration in minutes divided by 60, times your hourly cost rate. The hourly rate should include lost contribution margin, direct labor idled, and any overhead that keeps accruing. If a line costs 480 dollars per hour and stops for 35 minutes, the event costs 35 / 60 x 480 = 280 dollars. Summing this column across a month ranks failures by dollars rather than by frequency alone.

What downtime reason codes should I use?

Start with the seven built in categories: mechanical failure, electrical failure, tooling change, setup or changeover, operator, quality issue, and planned maintenance. Keep the list short, ideally under 12 codes, so operators actually use it consistently. Separate planned from unplanned, since planned PM should not count against reliability metrics like MTBF. Add plant specific codes only when a recurring cause does not fit an existing bucket, and document examples for each.

How do I build a Pareto from this downtime log?

At month end, sort the event log by category, sum downtime minutes per code, then order codes largest to smallest. Plot cumulative percent alongside. Typically the top 2 or 3 reason codes account for 70 to 80 percent of total downtime, which is the 80/20 rule in action. Attack those first. Build one Pareto by minutes for availability impact and a second by cost, since a rare long failure can outrank a frequent short one.

Should I track downtime by minutes or by number of events?

Track both, because they answer different questions. Total minutes shows availability impact and drives your Pareto, while event count reveals chronic nuisance stops. A code with 40 short events of 3 minutes totals 120 minutes but signals a reliability or setup problem worth a kaizen. One 120 minute breakdown has the same total but points to a spare parts or PM gap. The average event duration column separates the two patterns.

How does this downtime data feed OEE availability?

Availability equals runtime divided by planned production time, where runtime is planned time minus unplanned downtime. Sum the unplanned event minutes from this log, exclude planned PM, and subtract from planned production time. If a shift plans 450 minutes and logs 54 minutes of unplanned stops, availability is 396 / 450 = 88 percent. That figure multiplies with performance and quality to give OEE, so clean downtime logging directly sharpens your availability number.

How should I prioritize which downtime causes to fix first?

Rank by cost impact, not frequency, using the cost per event column summed by reason code. A code causing 6 hours a month at 480 dollars per hour costs 2,880 dollars and outranks a code with more events but lower total minutes. Weigh fix effort against that annualized cost: 2,880 monthly is roughly 34,500 dollars a year, which easily justifies a targeted PM change, a spare on the shelf, or a design fix.

Maintenance and Reliability

Downtime Tracker Spreadsheet Template

Log machine downtime events by reason code, duration, and cost to identify the top contributors and support root cause analysis.

Overview

This template gives maintenance planners, shift supervisors, and reliability engineers a structured log to capture every machine stoppage by reason code, duration, and cost. It is for teams that know downtime hurts but have no ranked data on which failures hurt most. Relying on memory at a review meeting buries the real drivers. A logged event with start time, end time, and a standard code turns vague complaints into a Pareto you can act on, and the cost column tells you where money is actually leaking.

Each event row records date, machine, shift, start and end time, duration in minutes, a category code, and a root cause note. Duration drives everything downstream: multiply it by your hourly cost rate divided by 60 to get cost per event. Seven starter categories cover mechanical, electrical, tooling, setup, operator, quality, and planned. The monthly summary rolls up total events, total downtime minutes, average and longest event, and the top category per machine so patterns surface without manual sorting.

In a real workflow, log events at shift end while causes are fresh, using your plant's standard code list so data stays consistent. At month end, sort by category to build a Pareto, where typically the top 2 or 3 codes drive 70 to 80 percent of downtime. Multiply minutes by cost rate to rank fixes by dollars, not just frequency. Pair it with the live Downtime Cost Calculator to price a single event instantly during the meeting.

What this template includes

Date, shift, and machine ID fields
Downtime start and end time
Reason code and category columns
Downtime duration auto-calculation
Hourly cost rate input for cost impact
Total downtime minutes and cost per event
Pareto-ready summary by reason code

Suggested use case

Use this to capture downtime on a shift log, prepare for a maintenance review meeting, or build a Pareto of the top downtime reasons for a CI project.

How to use it

Log each downtime event as it occurs or at shift end.
Enter the reason code from your standard list.
Enter your hourly cost rate to get financial impact.
Sort by reason code to build a Pareto at month end.
Use the cost column to prioritize which failures to fix first.

Frequently Asked Questions

How do I calculate the cost of a downtime event?: Cost per event equals duration in minutes divided by 60, times your hourly cost rate. The hourly rate should include lost contribution margin, direct labor idled, and any overhead that keeps accruing. If a line costs 480 dollars per hour and stops for 35 minutes, the event costs 35 / 60 x 480 = 280 dollars. Summing this column across a month ranks failures by dollars rather than by frequency alone.
What downtime reason codes should I use?: Start with the seven built in categories: mechanical failure, electrical failure, tooling change, setup or changeover, operator, quality issue, and planned maintenance. Keep the list short, ideally under 12 codes, so operators actually use it consistently. Separate planned from unplanned, since planned PM should not count against reliability metrics like MTBF. Add plant specific codes only when a recurring cause does not fit an existing bucket, and document examples for each.
How do I build a Pareto from this downtime log?: At month end, sort the event log by category, sum downtime minutes per code, then order codes largest to smallest. Plot cumulative percent alongside. Typically the top 2 or 3 reason codes account for 70 to 80 percent of total downtime, which is the 80/20 rule in action. Attack those first. Build one Pareto by minutes for availability impact and a second by cost, since a rare long failure can outrank a frequent short one.
Should I track downtime by minutes or by number of events?: Track both, because they answer different questions. Total minutes shows availability impact and drives your Pareto, while event count reveals chronic nuisance stops. A code with 40 short events of 3 minutes totals 120 minutes but signals a reliability or setup problem worth a kaizen. One 120 minute breakdown has the same total but points to a spare parts or PM gap. The average event duration column separates the two patterns.
How does this downtime data feed OEE availability?: Availability equals runtime divided by planned production time, where runtime is planned time minus unplanned downtime. Sum the unplanned event minutes from this log, exclude planned PM, and subtract from planned production time. If a shift plans 450 minutes and logs 54 minutes of unplanned stops, availability is 396 / 450 = 88 percent. That figure multiplies with performance and quality to give OEE, so clean downtime logging directly sharpens your availability number.
How should I prioritize which downtime causes to fix first?: Rank by cost impact, not frequency, using the cost per event column summed by reason code. A code causing 6 hours a month at 480 dollars per hour costs 2,880 dollars and outranks a code with more events but lower total minutes. Weigh fix effort against that annualized cost: 2,880 monthly is roughly 34,500 dollars a year, which easily justifies a targeted PM change, a spare on the shelf, or a design fix.