Mean Time Between Failures (MTBF) is the average operating time a repairable asset runs between one failure and the next. It is one of the oldest and most widely quoted reliability numbers in industry, and also one of the most misread. Treated carefully, MTBF tells you how often an asset interrupts production. Treated carelessly, it gets mistaken for a guarantee of how long a machine will last, which it is not. This guide defines MTBF precisely, walks through how to calculate it, and shows what the number can and cannot tell you. For the wider family of reliability metrics it belongs to, see our guide to equipment reliability.
What Is Mean Time Between Failures (MTBF)?
MTBF is the mean operating time between failures of a repairable system. The key word is repairable. When an asset fails, gets fixed, and returns to service, the clock starts again, and MTBF is the average length of those run-until-failure intervals. For parts you throw away rather than repair, such as a bearing or a light bulb, the equivalent metric is Mean Time To Failure (MTTF), which measures time to a single terminal failure. The IEEE draws the same line, treating MTBF as the metric for repairable systems and MTTF for non-repairable items, both derived from cumulative operating time and the count of failures, as its reference on the metric sets out.
Two misconceptions are worth clearing up at the start. First, MTBF is a statistical average across time or across a population of identical units, not a countdown timer on any single machine. Second, a high MTBF does not mean an asset will run trouble-free until it reaches that figure. As the calculation section shows, far fewer than half of a population typically survive to their stated MTBF. Both ideas trip up teams that read the number as a warranty rather than as a rate.
Why Does MTBF Matter for Reliability?
MTBF matters because it puts a single number on failure frequency, and failure frequency drives the most expensive event in most operations: unplanned downtime. According to Siemens' True Cost of Downtime 2024, unplanned downtime costs the world's 500 largest companies roughly $1.4 trillion a year, about 11 percent of their combined revenue and up from 8 percent in 2019 and 2020. Every one of those stoppages is a failure that shortened some asset's time between failures. Raising MTBF, in other words, is another way of describing the work of keeping production running.
Because it is a rate, MTBF also lets teams set targets, compare asset classes, and size the return on a reliability investment. A line whose critical drive has an MTBF of 2,000 hours behaves very differently from one at 8,000 hours, and knowing the gap tells you where to spend attention and budget. That is why MTBF sits at the center of most equipment uptime programs and feeds directly into maintenance planning. The caution is that MTBF describes what has already happened; it is a scoreboard, not a forecast for a specific machine, a distinction that becomes important later.
How Do You Calculate MTBF?
The formula is simple: MTBF equals total operating time divided by the number of failures over that period.
MTBF = total operating time / number of failures
Suppose a pump accumulates 10,000 hours of operating time and fails five times in that window. Its MTBF is 10,000 / 5, or 2,000 hours. The same formula works across a fleet. If 50 identical motors each run 1,000 hours, that is 50,000 unit-hours of operation; 10 failures across the fleet give an MTBF of 5,000 hours. Pooling units this way is how manufacturers arrive at the large MTBF figures quoted on spec sheets without waiting years to observe a single unit fail.
The detail most calculations get wrong is what counts as operating time. MTBF uses time the asset was actually running, not calendar time. Hours spent idle, waiting for parts, or under repair are excluded; folding them in inflates the number and hides the failures it is meant to expose. Repair time is captured separately by Mean Time To Repair. A second subtlety is the suspension, a unit that finished a test or observation window without failing. Those hours count toward total operating time even though no failure closed them out, which is why careful reliability testing tracks censored units rather than discarding them.
MTBF is closely tied to the failure rate. Under a constant failure rate, MTBF is simply the reciprocal of that rate, a relationship the US defense reliability literature has used for decades and which the National Academies restates in its review of MIL-HDBK-217: for constant failure rates, MTBF is the inverse of the failure rate. Electronics reliability often expresses the same idea as a FIT rate, the number of failures in one billion (10^9) device-hours. A component with an MTBF of one million hours has a failure rate of one per million hours, or 1,000 FIT. FIT and MTBF are two views of one quantity.
What Does MTBF Not Tell You?
The single most damaging error is reading MTBF as an asset's lifespan. It is not. When failures follow a constant rate, reliability over a period follows an exponential curve, R(t) = e^(-t/MTBF), so the probability that a unit is still running at time t falls off steadily. Set t equal to the MTBF itself and the math gives e^(-1), which is about 0.37. In plain terms, only about 37 percent of a population is statistically expected to survive to its own MTBF. A device rated at 100,000 hours is not promised to run 100,000 hours; that figure describes the rate of random failures during normal operation, not the point at which the unit wears out.
That constant-rate assumption is the fine print behind every MTBF figure, and it holds only during one phase of an asset's life. Components tend to follow a bathtub curve: a period of early failures from manufacturing or installation defects, a long stable middle where failures occur randomly at a low, roughly constant rate, and a final wear-out phase where the failure rate climbs. A peer-reviewed reliability analysis of medical linear accelerators describes MTBF as applying to this useful-life middle only, since early failures and wear-out both distort the average, in its study of failure modes and downtime. Apply an MTBF derived from the flat middle to a fleet of aging, wearing assets and it will badly understate the failures you are about to see.
MTBF vs MTTF and MTTR: Which Metric When?
MTBF is one of a small set of metrics that describe reliability, and choosing the right one is mostly about the question you are asking. Use MTBF for repairable assets when you want to know how often they fail. Use MTTF for non-repairable parts, where the meaningful event is a single terminal failure rather than a cycle of break and repair. Use Mean Time To Repair when the question is not how often an asset fails but how fast you recover once it does, since MTTR measures maintainability rather than reliability.
The two combine into availability, the share of time an asset is ready to run, calculated as MTBF / (MTBF + MTTR). This is where watching MTBF alone gets dangerous: a team can hold availability steady while MTBF quietly falls, simply by getting faster at repairs, which masks a machine that is failing more and more often. For the full treatment of how these metrics interlock, including overall equipment effectiveness, our equipment reliability guide covers the metric family end to end. The point to carry here is that MTBF answers one specific question, failure frequency, and pairing it with a recovery metric keeps that answer honest.
How Is MTBF Used in Design and Reliability Prediction?
MTBF is not only measured after the fact; it is also predicted before an asset exists. During design, engineers estimate a product's MTBF from its bill of materials, summing the failure rates of every component under expected operating and environmental conditions. Standards such as MIL-HDBK-217 formalize this with parts-count and parts-stress methods, applying a base failure rate to each component and adjusting for temperature, electrical stress, and quality, an approach the National Academies traces back through the reliability handbook literature in its review of MIL-HDBK-217. Predicted MTBF lets designers compare architectures, choose more reliable parts, and set warranty terms before the first unit ships.
Predicted MTBF and observed MTBF are different animals, and the gap between them is where reliability improves. A handbook prediction assumes idealized constant failure rates; the field reports what actually happened under real load, contamination, and duty cycle. Feeding field-reliability data back into design, so recurring failure modes inform the next revision, is the loop that separates a static spec from a product that gets more reliable over time. This is one place where richer operational data genuinely helps: the more faithfully a program captures how and why assets fail in service, the more useful that feedback becomes. It is worth being clear that a physical world model does not replace handbook prediction during design; its contribution is on the field side, turning messy real-world sensor data into a clearer picture of the failure modes a design should address next.
What Are the Challenges in Measuring MTBF?
The first challenge is that MTBF is a lagging indicator. It is computed from failures already recorded, so it tells you where an asset has been, not where it is heading. An MTBF trending down while availability holds steady is a warning that a team is compensating with faster repairs rather than fixing the underlying failure rate.
The second is data integrity. MTBF is only as good as the definitions behind it: what counts as a failure, what counts as operating time, and whether events are logged consistently across shifts and sites. Inconsistent records produce numbers that look precise but compare nothing. This is why the process industries developed ISO 14224, a standard for collecting and exchanging reliability and maintenance data so that failure records mean the same thing everywhere. The third challenge is aggregation. A single plant-wide MTBF averages together healthy assets and a handful of bad actors, and that average hides exactly the machines driving most of the loss. Tracking MTBF by failure mode and by asset class reveals far more than one headline figure. Underlying all of these is the constant-failure-rate assumption discussed earlier, which is routinely applied to assets well into wear-out, where it no longer holds.
Where Is MTBF Analysis Heading?
The direction of travel is away from population averages and toward per-asset condition. MTBF will remain a useful scoreboard, but it cannot tell an operator which specific machine is degrading right now or why, and that is the question modern maintenance is built to answer. The shift is from computing a reliability average after failures accumulate to detecting the degradation behind the next failure before it happens, which is the premise of condition-based maintenance and predictive maintenance. Encouragingly, the same Siemens data that priced downtime also found incidents growing less frequent even as each one costs more, a trend it attributes to digitization and predictive maintenance taking hold.
Physical AI platforms are the next step in that progression, which is why the honest way to describe their role is as a complement to MTBF rather than a replacement for it. Traditional anomaly detection leans on fixed thresholds or a separate model hand-built per machine, an approach that is slow to deploy and brittle across a mixed fleet. A physical world model like Newton, built by Archetype AI, learns how equipment behaves directly from sensor data such as vibration, temperature, current, and acoustics, which lets it recognize normal and abnormal states across many asset types rather than one. In one deployment at a process manufacturer, Newton fused more than 120 sensors per machine to pinpoint the signals behind each predicted break, reached roughly 84 percent failure-prediction accuracy, and prevented about half of unplanned breaks, deployed in weeks rather than the months a per-asset model would take. Because it can generalize, a single model has run zero-shot across gearboxes of varied sizes and manufacturers, and it can adapt to a new machine from as little as one labeled example, which matters in reliability work where real failures are rare by design. Running on an edge device on the asset, the same approach has separated healthy from degrading states across a fleet of roughly 400 wells in real time, naming the specific condition behind a fault rather than raising a generic alarm, which keeps more equipment running while cutting the false-alarm shutdowns that erode trust in monitoring. None of this changes how MTBF is calculated; it changes how early a team can act on the failures that pull MTBF down.
Frequently Asked Questions
How is MTBF calculated?
MTBF equals total operating time divided by the number of failures over that period. If a machine runs 10,000 operating hours and fails five times, its MTBF is 2,000 hours. Use operating time, not calendar time, and exclude hours spent idle or under repair, which are captured separately by Mean Time To Repair.
What is a good MTBF value?
There is no universal target; a good MTBF is one that meets the availability, cost, and safety goals for that asset class and duty cycle. Values span an enormous range, from hundreds of hours for heavily stressed mechanical parts to millions of hours for solid-state electronics, so MTBF is best compared against similar assets and against your own trend over time rather than an absolute benchmark.
Does MTBF predict how long a machine will last?
No. MTBF describes the rate of random failures during normal operation, not an asset's lifespan. Under a constant failure rate, only about 37 percent of a population is statistically expected to survive to its own MTBF, because reliability follows an exponential curve. Wear-out, which sets true end of life, is a separate phase the MTBF figure does not capture.
How does MTBF relate to predictive maintenance?
MTBF sets the baseline and measures progress; predictive maintenance is one of the main ways to move the number. Tracking MTBF tells you how often assets fail and whether reliability is improving, while predictive and condition-based programs catch degradation early enough to prevent the next failure, which is what raises MTBF over time.
