MTTR and MTBF: how to track them from your downtime log

Two acronyms show up the moment anyone starts taking reliability seriously: MTTR and MTBF. Mean time to repair, and mean time between failures. They sound like ratios you buy a system to compute, but they are just two averages pulled from records you probably already keep. If you log stops and you log repairs, you have the raw material. What you are usually missing is the discipline to match the two logs and divide.

This article shows exactly where each number comes from, how to compute both from a downtime log and a maintenance log, and the handful of mistakes that quietly corrupt them. We will track one machine across a full quarter so the arithmetic is concrete instead of abstract.

What each metric actually measures

MTTR and MTBF answer two different questions, and confusing them is the first mistake.

MTBF — mean time between failures — measures reliability. It asks: when this machine is running, how long does it typically go before it breaks? A high MTBF means failures are rare. It is a frequency metric, and it is driven by the condition of the asset — wear, lubrication, PM discipline, design.

MTTR — mean time to repair — measures recoverability. It asks: when the machine does break, how long before it is running again? A low MTTR means you recover fast. It is a response-and-repair metric, and it is driven by your maintenance process — how quickly a tech arrives, whether the spare is on the shelf, how hard the fix is.

The two are independent. A machine can be reliable but slow to fix (rare breakdowns, but each one strands the line for three hours waiting on a part). Another can be fragile but quick to recover (it jams constantly, but every clear takes four minutes). You need both numbers because they point at different fixes: MTBF at prevention, MTTR at response. If the difference between a downtime log and a maintenance log is still fuzzy, start with maintenance log vs downtime log — this article picks up exactly where that one ends.

The formulas, stated plainly

Both are averages, and both need a clean count of failures over a defined window.

The honest version of MTTR is the full stop-to-restart clock, because that is what production actually lost. That clock has two parts: the wait before a tech starts work, and the repair itself. The wait lives in your downtime log; the repair lives in your maintenance log. If you can split MTTR into those two pieces, do it, because a long MTTR driven by waiting is a different problem from one driven by hard repairs. If you can only capture stop-to-restart today, start there — it is the number production feels, and the split can come later.

MTBF = total operating time ÷ number of failures. Operating time is uptime — the hours the machine actually ran, not the hours it was scheduled. Count only unplanned failures, not planned stops.
MTTR = total repair time ÷ number of failures. Here is the fork that trips people up: "repair time" can mean the wrench time alone, or the whole stop from the moment the line went down to the moment it restarted. Both are valid. They answer different questions, so pick one, write it down, and stay consistent.

A worked quarter on one machine

Take one injection-molding press over a 13-week quarter. It runs two shifts, five days a week — roughly 1,000 scheduled run hours for the quarter. Over that window the machine lost 60 hours to all stops combined: changeovers, PM, material waits, and breakdowns. That leaves 940 operating hours.

Of those stops, eight were unplanned breakdowns — the only events that count toward MTBF and MTTR. Here they are, matched from the two logs by machine and timestamp, with the wait and repair split out.

That is everything you need. Now divide.

MTBF = 940 operating hours ÷ 8 failures = 117.5 hours. On average, the press runs about 118 hours between breakdowns. At 80 scheduled hours a week, that is roughly a week and a half.

MTTR, stop-to-restart = 780 minutes ÷ 8 failures = 97.5 minutes per failure. That is the number production feels.

Now split it, because the split is where the action is:

So of every 97-minute breakdown, about a quarter is waiting and three-quarters is repair. That tells you where to push. Shaving the wait with faster escalation buys you 22 minutes a failure at best; the repair time is the bigger lever, and it points at spares, training, and whether the hard jobs have a documented procedure.

Mean response time = 175 ÷ 8 = 22 minutes of waiting before a tech touched the machine.
Mean repair time = 605 ÷ 8 = 76 minutes of actual wrench time.

Turn the same data into availability

The reason to bother is that these numbers roll straight into OEE. Availability — the first term of OEE — is operating time over scheduled time:

Availability = 940 ÷ 1,000 = 94.0%.

The two reliability metrics explain part of that percentage, and it pays to be precise about which part. There is a clean identity: MTBF ÷ (MTBF + MTTR) is the availability you would have if breakdowns were the only thing stopping the machine. Plug the quarter in — 117.5 ÷ (117.5 + 1.6 hours of MTTR) — and you get 98.6%. That is the same as 940 ÷ (940 + 13 hours of breakdowns).

The gap between 98.6% and 94.0% is the other 47 hours: changeovers, PM, and material waits. So the headline availability has two layers. MTBF and MTTR own the breakdown layer; planned stops own the rest. Raising MTBF (fewer breakdowns) or cutting MTTR (faster recovery) both move the first layer, and shorter changeovers move the second. A plant chasing OEE should track all three numbers, not just the headline percentage, because the percentage alone will not tell you which layer is costing you. If you want the full availability walkthrough and the traps that inflate it, see how downtime feeds OEE availability.

Read the trend, not the single number

A single quarter's MTBF is a baseline, not a verdict. The value shows up when you track it across quarters and watch which way it moves. Suppose you notice the same two failure modes repeating — heater bands (events 1 and 8) and hydraulic hoses (events 2 and 6). You add a PM: scheduled heater-band inspection and a hose-replacement interval based on run hours. Next quarter, those four failures drop to one.

Notice the two metrics moved differently. MTBF jumped because you prevented failures — that was the PM working. MTTR barely budged, because preventing a breakdown does nothing to speed up the ones that still happen; that is a separate project. Reading them side by side keeps you honest about which lever actually moved. For the broader playbook that turns this ranking into fixes, see how to reduce unplanned downtime, and to find which failures to target first, build a downtime Pareto.

Mistakes that corrupt both numbers

Counting planned stops as failures. A changeover is not a breakdown. If your failure count includes scheduled PM and die changes, MTBF collapses and means nothing. Every stop needs a planned/unplanned flag before you count.
Using scheduled time instead of operating time for MTBF. MTBF is about how long the machine runs between failures, so the numerator is uptime, not loading time. Use scheduled hours and you overstate reliability.
Mixing MTTR conventions. Half your records measure wrench time and half measure stop-to-restart, and the average is meaningless. Pick one definition per report and label it.
Leaving the clock running overnight. A stop logged at the end of second shift and closed at the start of first shift records twelve hours of downtime for a machine that was never scheduled to run. One of those will double a month's MTTR. Make open stops impossible to miss, and let someone correct the end time when it happens.
No shared key between the logs. If the downtime entry and the repair record do not share a machine ID and a timestamp, you cannot match them, and you cannot split MTTR into wait and repair — the most useful cut you have.
Averaging across wildly different machines. A plant-wide MTTR that blends a 4-minute jam clear with a 6-hour gearbox swap tells you nothing actionable. Compute per asset, then roll up.
Too few failures to mean anything. Eight failures is a usable sample; two is an anecdote. Early on, widen the window before you trust the average.

Where HelpFab fits

You can compute both metrics in a spreadsheet, and plenty of plants do. The friction is always the same: the stops live in one file, the repairs live in another, and matching them by hand every quarter is the chore that kills the habit.

HelpFab keeps both against the same machine. Operators log every stop from a phone or tablet in Downtime tracking by tapping an issue type and, when the type covers more than one machine, the machine it happened on. Each issue type carries a planned-downtime flag, so changeovers and PM are counted as downtime but never as failures. A type can also raise a maintenance request the moment the operator logs the stop, with the operator's note attached, so the fix record hangs off the breakdown that caused it instead of living in a separate list.

From there the division is done for you. Each machine's page shows MTBF, stop-to-restart MTTR, failure count, and availability for any date range, with a month-by-month trend, using the machine's scheduled hours and the stops logged against it. Open stops show on the overview so a timer left running overnight gets caught the next morning, and an end time can be corrected when it happens.

Whatever you use to hold the data, the method does not change: flag planned versus unplanned, count failures over a defined window, divide operating time for MTBF and repair time for MTTR, and split that MTTR into wait and wrench when you can so you know which problem you actually have. Then watch the trend. One quarter is a number; a line of quarters is a reliability program.

Latest articles

A production downtime report example, daily and weekly — A worked production downtime report for a CNC cell, the four numbers managers actually read, and a layout that turns lost minutes into action.
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.