MTBF (Mean Time Between Failures): Definition, Calculation and Limits

MTBF means mean time between failures: in maintenance reporting, it measures the average operating time per counted failure of a repairable asset. The two inputs are accumulated operating hours and counted failures, explored in the worked calculations below.

NIST’s repairable-system definition covers systems that can be restored to satisfactory operation, including through parts replacement or changes to adjustable settings. For maintenance reporting, define whether the measured asset is one machine, a subsystem or a complete line before collecting its failures.

Report the value with four boundaries so another reader can understand what it describes:

• Asset or system: identify the equipment and which connected components fall inside the measurement boundary.
• Observation window: give the start and end dates for both the hours and the failure count.
• Operating-time basis: state what qualifies as operating time and which periods are excluded.
• Counted failure population: identify the interruptions included and apply the same counting rule throughout the window.

Treat this observed-window result as a description; forecasting limits are covered in the pitfalls section.

Keep operating context beside the number. Where relevant, connect interruptions to batch execution history, and use batch comparisons to structure questions about differing conditions. The central operational question is: which interruptions are occurring, under which operating conditions, and what decision will this measure support?

The checklist below proposes local measurement rules for the repairable assets defined above; it is not an official reliability terminology standard.

• Required function: specify what the equipment must deliver and under which operating conditions.
• Failure threshold: define the observable loss of function that qualifies as a counted failure.
• Equipment boundary: identify included components, utilities and interfaces; decide how shared-service interruptions are classified.
• Time basis: identify qualifying operating states, counter units and the reporting window.
• Reporting owner: name who resolves ambiguous classifications and approves measurement-rule changes.

Ask four classification questions: Did the stopped asset lose its required function, or was no production requested? Does reduced-speed operation breach the failure threshold? Did an operator-cleared interruption involve functional failure, despite needing no replacement part? Was a planned intervention preventive, or did it address an existing failure? Document answers rather than treating every stop as equivalent.

Keep a separate timestamp for every stage in the workflow above, including agreed restoration and the return to the applicable operating state, even when two stages coincide; they are distinct recorded events. State which endpoints define the local repair-time measure and what confirms agreed restoration. Preserve these distinctions in the process event log.

Specify window start and end, endpoint inclusion, time zone and counter units, such as operating hours. For events spanning closure, state the failure-count assignment and allocate time consistently across windows. Keep unresolved events open, identify incomplete restoration durations, and define how later closure updates the report; do not invent a completion timestamp.

Frequency, restoration duration and first-failure lifetime answer different questions. Beyond the repairable systems defined above, NIST §8.1.2.1 also describes non-repairable populations, whose failed members are permanently removed, so their first-failure lifetime is not an MTBF. It uses rate of occurrence of failure for repairable systems; failure-rate or hazard-rate terminology applies to first failures in non-repairable populations. Replacing a component can restore the system without restoring that component to its original population.

Use the following working definitions for an operational comparison, not as interchangeable labels:

Check the local expansion of MTTR: does the report mean time to repair or time to restore? Record whether timing begins at failure, detection or repair start, and ends at repair completion or return to service. Specify how waiting, testing and restart are treated. Keep these definitions alongside the operation-phase measurement rules.

For positive operating time T and failure count n, the observed operating-time-per-event ratio is T/n; its reciprocal is n/T. That arithmetic uses the same events and time boundary. It does not establish a population hazard function or demonstrate constant behaviour. The dedicated availability section explains its calculation; neither MTBF nor MTTR alone answers the availability question.

Case 1: one repairable asset

Assume one repairable asset is observed over one defined window. Complete event records show 1,200 operating hours and six counted failures. Restoration time is excluded from those operating hours. All six events have been completed, with 30 total restoration hours measured using the agreed restoration boundary.

• Observed MTBF: 1,200 operating hours ÷ 6 failures = 200 hours per failure.
• Reciprocal observed occurrence ratio: 6 failures ÷ 1,200 operating hours = 0.005 failures per operating hour.
• Mean restoration duration: 30 restoration hours ÷ 6 completed events = 5 hours per restoration.

Here, 0.005 is a ratio calculated from the observed window; the pitfalls section explains why it is not a forecast.

Sensitivity check: if review reclassifies one of the six events as a planned stop rather than a counted failure, the same 1,200 operating hours give 1,200 ÷ 5 = 240 hours instead of 200. A 20% change from one classification decision is why the failure definition must be fixed before results are compared across periods or assets.

Keep the two time totals separate: 1,200 hours measures operation; 30 hours measures restoration. Adding restoration hours to the MTBF numerator would change the measurement boundary rather than improve the calculation.

Case 2: two comparable assets

In a separate hypothetical comparison, assume comparable assets A and B use the same failure-counting and operating-time rules, with complete records. A contributes 600 operating hours and three failures; B contributes 400 operating hours and one failure.

The unweighted average of the two asset results is (200 + 400) ÷ 2 = 300 hours per failure. That is not the pooled result: it gives each asset’s ratio equal weight instead of dividing combined operating time by combined failures. For this pooled calculation, retain the original hours and counts rather than averaging reported MTBF values.

Before pooling in practice, document why the assets belong in the same comparison: their duty, operating conditions and failure definitions should support the intended decision. For example, equal counting rules alone do not resolve different loading or service duties. Keep individual results visible alongside the pooled value in asset lifecycle management. Mathematical aggregation is possible even when the operating populations are not meaningfully comparable.

Worked case 3 continues the first hypothetical asset: six failure events, 1,200 operating hours and 30 restoration hours associated with those same events. Assume the observation window contains only operating and restoration time, with no standby, planned-stop or other time categories. Its total duration is therefore 1,230 hours.

• Observed operating fraction: 1,200 ÷ 1,230 = 40/41, or approximately 97.56%.
• MTBF for this case: 1,200 operating hours ÷ 6 events = 200 operating hours per event.
• Mean restoration time, labelled MTTR here: 30 restoration hours ÷ 6 events = 5 restoration hours per event.
• Equivalent ratio: 200 ÷ (200 + 5) = 40/41, again approximately 97.56%.

The shared six-event denominator makes the two ratios arithmetically equivalent: dividing both time totals by six does not change their ratio. This is a bounded observed result, not a universal availability formula. Before treating it as a long-run availability estimate, specify an explicit reliability and restoration model rather than relying on this identity alone.

For your actual availability definition, which additional intervals belong in the denominator? Decide how to classify waiting for personnel, spares, testing or an authorised return-to-service decision. State whether each interval is included in restoration time, excluded from the reporting window or recorded separately. When using machine-state records through a MES–historian integration, reconcile those records with the chosen restoration boundary.

The percentage is a maintenance measure, not a return-to-service or release decision; see the regulated-manufacturing section, and connect the event to its deviation record where relevant.

Calculating operating hours divided by counted failures describes the observation window. Treating its reciprocal—failures per operating hour—as a stable future occurrence rate is a separate modelling assumption. As a practical reporting rule, keep the measured ratio distinct from any forecast based on it.

NIST §8.1.2.4, “Bathtub” curve describes an initially decreasing failure-rate region, a roughly constant region and an increasing wearout region. Its discussion concerns empirical population behaviour as units age; it also extends the curve to repairable systems, where the vertical axis represents repair rate or rate of occurrence of failures. This is not a method for assigning an individual asset to a life stage from its MTBF value alone.

Practical interpretation checks

• Asset age: compare age profiles and major replacements using the asset’s lifecycle history, rather than assuming two identical models have equivalent histories.
• Production duty: check running speed, load, starts and stops, and product mix before comparing periods or assets.
• Operating environment: review changes in temperature, moisture, contamination or utilities; a focused gemba observation can structure that review.
• Event classification: confirm that both comparisons count the same kinds of failures and use the same operating-time boundary.
• Observation window: show its dates, operating-hour exposure and event count beside MTBF. Examine shorter subperiods for changing behaviour rather than relying only on the combined average.

For short windows or sparse event histories, treat apparent improvement cautiously: ask whether the comparison reflects changed conditions or merely a different observation period. Keep confidence limits and failure-probability estimates separate unless their statistical model and assumptions are defined.

Use event classification to connect the MTBF result to investigation. A practical structure keeps four fields separate in the event traceability model:

• Observed symptom: what the operator saw, such as loss of flow.
• Affected component: the identified asset part, or “not yet established”.
• Assigned failure mode: how that component failed; retain a provisional label until supported.
• Investigation status: open, under investigation or concluded, with the supporting finding linked.

NIST §8.1.8.1, Competing risk model, evaluates component reliability from individual failure-mode models. Its three assumptions are:

1. Failure mechanisms proceed independently, at least until a failure occurs.
2. The component fails when the first competing mechanism reaches failure.
3. Each failure mode has a known life distribution model.

This is a component reliability model, not the pooled operating-time calculation in the worked example. Assigning event codes does not establish those assumptions.

For a proportionate investigation, ask:

• Recurring mode: does the evidence indicate the same mechanism, and did the previous action address it?
• New mode: is this genuinely new behaviour, or a change in detection or classification?
• Changed interruption-duration distribution: which events account for the shift, and what changed in diagnosis, access, repair or restart?

Use the investigated mechanism and operational consequence to select controls; FMEA can structure that discussion. Define an owner, observation window, comparable operating exposure and event-level review criteria before implementation. Then check subsequent events for recurrence, duration and unintended effects rather than assuming that the selected control improved reliability.

Use the following proposed evidence model to make an MTBF result reproducible. These are measurement controls, not regulatory requirements or claims about software integrations.

Connect records without equating them

Data-model diagram: Asset identity → exposure records Asset identity → failure events → restoration records Failure events ↔ work-order links ↔ maintenance work orders Exposure records + selected failure events + restoration records → versioned calculation → reviewed result

Equipment counters could supply operating-time readings; operator entries in a process event log could identify interruptions; maintenance work orders could support repair and restoration details. Design MES–CMMS reconciliation around explicit links, rather than counting work orders as failures.

• Interruption without a work order: does it meet the event definition, and what record supports classification?
• Several work orders for one failure: which event identifier joins them without multiplying the count?
• One work order covering several assets: which assets actually failed, and how are activities allocated?
• Restoration entered retrospectively: what supports the effective restoration time, separately from its entry timestamp?

Recover exceptions explicitly

Preserve stable source identifiers and source-system names. Give each exception an explicit status, owner and documented correction reason; retain original values alongside corrections.

• Duplicate imports or interrupted transfers: match source identifiers, isolate repeats, resume from a reconciled checkpoint and compare source and received totals.
• Missing readings or counter resets: flag affected intervals; resolve from supporting records or document exclusion or estimation rather than silently bridging the gap.
• Inconsistent units or time zones: retain original units, timestamps and offsets; record conversions to the calculation’s common unit and time basis, and flag ambiguous local times.

Retain the calculation version, event-definition version, observation window, included event identifiers, source totals, accepted exposure total and failure count with each reviewable result. Link every corrected result to its previous version. A named reviewer should decide whether unresolved exceptions justify withholding the result, restricting its use or accepting it with a documented qualification.

Binding law: check applicability by product, activity and location before connecting MTBF to compliance. This table proposes scope questions and coordinating owners—not statutory assignments or mandatory MTBF targets.

Official technical guidance: the NIST distinction between repairable and non-repairable items is modelling context, separate from legal applicability.

Industry reporting conventions: name ISO 22400 as KPI-standard context and check its current scope before referencing it in a reporting specification; an MTBF report is not a certification claim.

Software support: evaluate calculation traceability and review controls separately. Keep equipment-performance review distinct from equipment-use authorisation and product disposition; route those decisions to authorised people under the site's applicable procedures.

Begin with the decision under consideration: investigation priority, inspection review, spare-parts planning, a maintenance-method change or further observation. Treat the following as a proposed maintenance-review workflow, not an MTBF acceptance standard. Before comparing periods, check the definitions, exposure basis, operating duty and calculation versions established above; resolve differences before interpreting a movement as deterioration or improvement.

Include the production consequence and the nature of the interrupted function in the review. Ask whether the interruption stopped throughput, disrupted a process-control function or affected containment, and identify what assessment is needed. Do not rank assets solely by their averages. A focused gemba review can be used to examine the operating conditions behind the recorded events.

For the selected action, name an accountable owner, record the rationale and choose a follow-up window suited to operating exposure, event frequency and consequence. If changing the maintenance method, connect the proposal to the site's change-control process. Do not derive a universal review cadence, alarm threshold or replacement interval from this table.

Keep the decision to act separate from the later assessment: first record the intended change and how it will be assessed; later compare the agreed observations. Completing the task is not, by itself, evidence that the intended change occurred.

Use this proposed operational checklist to start with a bounded asset group, an observation period and named owners for definitions, event reconciliation, calculation and operational review. Keep the first implementation small enough that reviewers can trace every contributing event.

Accept the measurement process

• Confirm consistent time units and clear boundaries between operating, stopped and restored states.
• Reconcile counted failures against the underlying process event log; document exclusions and their reasons.
• Have a second reviewer reproduce the reported calculation from retained inputs, without relying on an unexplained dashboard value.
• Test a duplicate event, a missing counter reading, an incomplete restoration record and a corrected event classification. For each, record the expected treatment and compare it with the actual reporting behaviour.
• Check whether asset modifications, definition revisions and calculation changes remain distinguishable in trend reviews; mark affected periods rather than silently combining unlike results.

Evaluate software and close the review

Ask software providers to demonstrate these questions using the test cases above:

• Can users inspect the events contributing to each result?
• Can an audit trail preserve corrections and their reasons?
• Are unresolved exceptions distinguishable from accepted records?
• Can users export the calculation inputs, including units, observation boundaries and the applicable calculation version?

End with a short review record: result, material limitations, decision owner, agreed action and follow-up evidence, with approval kept as described in the regulated-manufacturing section.