What are MTBF and MTTR?

MTBF (Mean Time Between Failures) describes how long a repairable asset operates, on average, between defined failures. MTTR (Mean Time To Repair) describes the average time needed to return that asset to an operational state after a defined failure. The first is a reliability measure; the second concerns maintainability. Both are averages calculated from observed events, not promises about when the next failure will occur or how long every repair will take.

The numbers are meaningful together only when they refer to the same asset, observation period, and event rules. Change the definition of a failure, the operating-time boundary, or the point at which repair is considered complete, and the resulting metric changes. NIST's reliability glossary explicitly excludes waiting for and performing repair from the operating time represented by MTBF. Treating calendar hours or every kind of stoppage as operating time is therefore a common source of misleading results.

How is MTBF calculated?

The practical formula is MTBF = total operating time / number of failures. Operating time is the time the asset actually ran within the defined observation period. Planned off-time, waiting for maintenance, and post-failure repair are not added to its numerator. Failures must be counted under the same rule throughout the period.

Suppose a CNC machine operated for 300 hours and experienced three in-scope failures. Its observed MTBF is 300 / 3 = 100 operating hours. That does not mean the machine will fail precisely every 100 hours. The three intervals may differ substantially, and an average hides that spread. A figure based on very few events should not be treated as a permanent characteristic of the asset.

Does “failure” mean only a complete stop, or also reduced speed and unacceptable output? Those definitions lead to different results. Changes in product mix, duty cycle, and asset configuration complicate comparisons further. A useful MTBF report shows the event definition, period, failure count, and data coverage beside the headline number.

How is MTTR calculated?

MTTR = total defined repair time / number of completed repairs. If those three failures took 1, 2, and 3 hours to return the machine to operation, the total is 6 hours and MTTR is 6 / 3 = 2 hours. That average represents both a short and a long intervention; the individual event durations still matter.

Teams also use MTTR to mean “mean time to recovery” or “mean time to restore”. The phrases do not necessarily share the same endpoint. Is the measure limited to active technician work? Does it include waiting for a part, safe cool-down, testing, and production restart? Name the measured interval explicitly. Do not silently combine hands-on repair with the whole production stoppage under one label. IBM's maintenance discussion illustrates how notification, repair, testing, and restart boundaries affect the measure.

What do the two measures say together?

In the illustrative example, the machine operated for 300 hours and spent 6 hours in the defined failure-related repair state. With consistent boundaries, 300 / (300 + 6) ≈ 98.04%. The equivalent simplified relationship is MTBF / (MTBF + MTTR) = 100 / (100 + 2) ≈ 98.04%. This is a simplified availability relationship, not automatically the same as every factory's availability report or the Availability component of OEE.

OEE separately requires a definition of planned production time and the treatment of planned and unplanned stops. MTBF and MTTR here focus on particular failure and repair events. Adding hours when the machine was shut down outside planned production to MTBF inflates it artificially. Classifying material shortage or quality-approval waiting as “repair” misrepresents maintenance performance. Those losses still need recording, but under the right event category.

What events should be collected?

At minimum, distinguish asset identity, failure onset, failure category, response start, technical repair completion, test completion, and return to production. Each timestamp needs a known source and time zone. An operator report and a PLC stop signal may describe the same event; counting them as two failures lowers MTBF incorrectly. Event order must also survive a network outage and delayed data delivery.

A MES may connect a stop to an asset and production order, while a maintenance system records the cause, work order, spare parts, and repair steps. Allocate these responsibilities by data ownership, not product name. An automatic counter alone does not establish root cause; a maintenance ticket alone may not measure the exact production loss. The records need to be reconciled through a common asset and event identity.

Common interpretation errors

A high MTBF does not always prove good maintenance. A lightly used asset may fail rarely, while one long interruption on a critical asset may dominate business impact. A low MTTR is not always good either: a quick temporary fix followed by repeated failure has not improved reliability. Examine recurrence, severity, safety, and quality consequences alongside the averages.

MTBF is not a production target or a warranty period. An average alone says little about the distribution of failures, asset age, or operating conditions. For a non-repairable item, MTTF (Mean Time To Failure) may be the more appropriate lifetime measure. Comparisons call for a similar asset class, load profile, and failure definition.

To begin, select one critical asset family and an observation period long enough to capture meaningful events. Agree on a failure dictionary with production and maintenance, reconstruct several event timelines, and recalculate the formulas from raw records. Then ask which failures recur and which step consumes repair time, rather than making the averages targets in isolation. MTBF and MTTR are most useful when they expose specific improvement questions.