MTBF Formula: How to Calculate MTBF With Examples

Almost everyone who asks me how to calculate MTBF already knows the formula. They can recite it. What they cannot do is defend the two numbers they put into it, and that is the whole problem. MTBF is a ratio of total operating time to number of failures, so the arithmetic takes seconds. Deciding which hours count as operating time, and which events in a work order history count as failures, takes a conversation with operations, a look at how the CMMS actually captures downtime, and a decision you write down so the next person calculates it the same way. This guide walks the calculation end to end, with worked examples on hypothetical numbers, and then shows you the four data problems that most often make a technically correct MTBF figure useless in practice.

The message up front: the MTBF formula is total operating time divided by number of failures. A very common error in industry is substituting calendar time for operating time, which inflates the result on anything that is not running continuously. Another common error is counting every work order as a failure. Fix those two inputs and your MTBF becomes comparable over time, which is the only thing that makes it worth calculating at all.

This page deliberately stays on the calculation. If you want the concept, what MTBF represents, what it does not represent, and why treating it as an expected lifetime is a mistake, that argument lives in MTBF explained. If you want MTBF placed alongside MTTR, MDT and availability as a definitional set, that is the reliability metrics guide. Here we compute.

1. The MTBF formula

MTBF is mean time between failures. The formula is an arithmetic definition, not a model, and it is safe to state plainly:

That is it. Two inputs, one division, and a result expressed in whatever time unit you used for the numerator. Hours are the usual unit for plant and rotating equipment because CMMS run-hour meters and SCADA historians record hours. Some fleets use kilometres or cycles instead, and that is perfectly valid: the formula does not care whether the denominator of "time" is clock hours, running hours, kilometres travelled or duty cycles, as long as you are consistent and you label the unit on every report.

The formal vocabulary for this family of terms lives in IEC 60050-192:2015, the dependability part of the International Electrotechnical Vocabulary, which supersedes the older IEC 60050-191:1990 that a lot of older training material still cites. I would not build a calculation procedure around a paywalled vocabulary standard, but it is the right reference to name when someone in a review meeting insists their definition is the standard one. The IEC publishes the vocabulary online through Electropedia , and the full standards catalogue sits on the IEC Webstore .

There is a related metric, MTTF, mean time to failure, which applies to items that are not repaired but replaced. The arithmetic looks similar and the two get used interchangeably in vendor literature, which is wrong. If you are computing for consumable or non-repairable items, read the MTTF formula and examples before you label your result MTBF.

2. What counts as operating time

Operating time is the time the item was actually performing its function. Not the time it existed. Not the time it was available. The time it was running.

That sounds obvious and it is routinely ignored, because calendar time is the number that is easiest to get. Nobody has to instrument anything to know that a quarter contains about 2,160 hours. So the calculation gets done on calendar hours, and the resulting MTBF is inflated by exactly the ratio of calendar time to run time. On a standby generator that runs a few hours a month, that inflation factor can be enormous, and the reported MTBF becomes a number about the calendar rather than about the machine.

Here is what I would include and exclude:

• Include: hours the asset was energised and performing its duty, including at part load. A pump throttled back is still operating.
• Exclude planned shutdowns: turnarounds, seasonal shutdowns, planned outages where the asset was deliberately not running. It cannot fail while it is not being asked to work.
• Exclude repair and waiting time: the hours between a failure and the return to service are downtime, not operating time. Strictly, this is the difference between MTBF and mean time between maintenance actions, and mixing them is one reason two departments compute different numbers from the same history.
• Exclude time the asset was installed but not commissioned: a unit sitting in a plant room awaiting handover has accumulated zero operating hours.
• Decide explicitly about idle standby: for duty and standby pairs, a standby unit accumulating no run hours is not accumulating exposure either. If you count its calendar time you will report a flatteringly high MTBF for the unit that has barely worked.

Where does operating time come from in practice? Three sources, in descending order of trustworthiness: a run-hour meter or SCADA tag read directly from the machine; a calculated figure from production or duty schedules; and, last and weakest, an assumption applied uniformly across an asset class. The first is the only one I would report externally. The second is usable if you document the assumption. The third is a placeholder, and it should be labelled as one on the face of the report so nobody downstream treats it as measured.

This is where the maintenance system earns its place in the calculation. A CMMS is usually where the two inputs converge: the meter readings that give you operating hours, and the closed work order history that gives you failure counts. Any CMMS can do this arithmetic. The question is whether your meters are being read and whether your failure records are coded well enough for the count to mean anything, and no software fixes either of those for you.

3. What counts as a failure

A failure is the loss of the item's ability to perform its required function. It is not "an event that generated a work order", and that substitution is the second great MTBF error.

The reason people make it is that the work order table is queryable and a failure definition is a judgement. Counting work orders is one SQL statement. Deciding whether a filter change, an operator-reported noise that turned out to be nothing, and a valve adjusted during a routine round are failures requires somebody to think. So the easy count wins, the denominator inflates, and MTBF collapses to a number that mostly reflects how enthusiastically your technicians raise work orders.

What I would exclude from the failure count:

• Preventive and scheduled work: a PM task is planned work, not a failure. If your count includes PMs your MTBF will fall every time you improve your PM programme, which is exactly backwards.
• Modifications, upgrades and installs: capital and improvement work is not a failure event.
• No-fault-found calls: an inspection that found the asset healthy is not a failure of the asset, though a pattern of them is worth investigating separately as a reporting or instrumentation issue.
• Duplicate records for one event: a single breakdown often spawns a corrective work order, a parts requisition and a follow-up. That is one failure.
• Failures of something else: a pump stopped because upstream power was lost has not failed. Attribution to the correct asset is the most tedious part of the cleanup and the part that changes the answer most.
• Cosmetic and non-functional defects: a damaged guard, corroded paint or a missing label is a defect to fix, not a loss of function, unless your functional definition says otherwise.

What I would include: any event where the asset could no longer deliver its required function, including partial functional failures where it still ran but outside its specification. That last category is the one teams argue about. A chiller producing cooling but not to setpoint has partially failed against its function, and if you exclude partial functional failures you will report a comfortable MTBF while operations complains constantly. My recommendation is to include them and to flag them separately, so you can report both a total failure count and a complete-loss-of-function count without recalculating from scratch.

None of this works without disciplined failure coding. A problem, cause and action structure on every corrective work order is what lets you filter a failure count out of a work order table months later. If your history is closed out with free text and nothing else, the honest answer is that you cannot compute a defensible MTBF from it yet, and the first project is the coding, not the metric. Where failure data conventions matter across an organisation, ISO 14224:2016 is the reference: it is the collection and exchange standard for reliability and maintenance data in the petroleum, petrochemical and natural gas industries, and its equipment taxonomy and failure-mode structure are widely borrowed outside those industries. Note that OREDA, which is often mentioned in the same breath, is a proprietary members-only database rather than a standard. The ISO catalogue is at iso.org .

4. The inputs table

This is the table I would put on the first page of any MTBF reporting specification, because it settles the two arguments before they start.

5. Worked example one: a single machine over a year

All numbers in this section and the next two are my own hypothetical, illustrative figures chosen to make the arithmetic clear. They are not benchmarks, they are not drawn from any real site, and they should not be used as targets for any equipment class.

Illustrative scenario. One process pump, monitored for a full calendar year. The run-hour meter, read at the start and end of the window, shows 4,200 operating hours. During the year the pump suffered six events that met the failure definition: three bearing failures, two seal failures and one coupling failure. A two-week planned shutdown and all PM interventions are excluded from both inputs.

Now the error. Suppose the analyst had no meter reading and used calendar hours instead. A non-leap year is 8,760 hours, so the same six failures would have produced 8,760 divided by 6, which is 1,460 hours. The same machine, the same failures, an MTBF reported at more than double the honest figure, purely because the numerator counted hours when the pump was standing still. This is the most common MTBF error in industry and it is entirely invisible in the final number: 1,460 hours looks just as respectable as 700.

The second thing worth noticing is that this result is an average across three different failure mechanisms. Bearings, seals and couplings degrade differently and respond to different interventions. A single 700 hour figure tells you the pump interrupts production roughly every 700 operating hours, which is useful for planning, but it tells you nothing about what to fix. That limitation is discussed in section nine.

6. Worked example two: a fleet, in unit-hours

Again, illustrative numbers of my own.

Illustrative scenario. Twelve identical booster pumps, same make, model, size and duty, monitored over one quarter. Each pump has a run-hour meter. The recorded run hours vary by pump because the control system rotates duty, and the total across all twelve comes to 18,000 unit-hours. Across the fleet there were 24 qualifying failures in the quarter.

The key move is the unit. The numerator is unit-hours, the sum of operating hours across every unit in the population, not the elapsed length of the window. The result is then an MTBF per unit, which is the number you want, because it is comparable to the single-machine figure from the previous example and to the same fleet's figure next quarter.

The error to avoid here is seductive. A quarter is roughly 2,160 hours of elapsed time. Divide that by 24 failures and you get 90 hours, which looks alarming and is meaningless: it is the mean interval between failures somewhere in the fleet, not the mean operating time between failures of a pump. Both quantities have uses, and the first one is genuinely useful for staffing a maintenance crew, but only one of them is MTBF, and reporting the fleet interval as if it were per-unit MTBF will make healthy equipment look catastrophic.

Fleet aggregation is also the one context where MTBF starts to become statistically respectable. Twenty-four failures is a far better basis for a mean than six. The price you pay is that the mean now hides variation between units: if two of the twelve pumps produced most of the failures, the fleet MTBF will look acceptable while two specific machines are quietly generating the workload. I would always report the fleet MTBF alongside a per-unit failure count so the outliers are visible.

7. Worked example three: partial periods and units still running

The realistic case. Illustrative numbers again, and this one includes the situation people most often get wrong: units that were not exposed for the whole window, and units that have not failed at all.

Illustrative scenario. Five air handling units, same model, monitored over a window in which a fully exposed unit would accumulate about 2,000 operating hours.

Seven qualifying failures were recorded across the five units in the window.

The naive version assumes all five units were exposed for the full 2,000 hours, giving 10,000 unit-hours, 10,000 divided by 7, and an MTBF of about 1,429 hours. That is 64 per cent higher than the defensible figure, and the inflation comes entirely from crediting the calculation with exposure that never happened.

Two points about the units that did not fail. First, AHU-4 contributes its 2,000 operating hours to the numerator and zero to the denominator. That is correct: hours of successful operation are evidence of reliability and they belong in the calculation. Beginners sometimes drop non-failing units entirely on the grounds that they have no failures to count, which throws away the best evidence in the dataset and drives MTBF down.

Second, and more subtly, the hours logged by a unit that has not yet failed are not a complete time-between-failures observation. They are a partial one, cut short by the end of the window rather than by a failure. Statisticians call this censoring, and the simple MTBF formula handles it only crudely. That is section nine.

8. The three examples side by side

All figures below are illustrative and internally consistent with the sections above. No figure here is a target or a benchmark for any equipment class.

The pattern across all three is the same: every error runs in the direction of flattering the equipment. Calendar time inflates. Assumed full exposure inflates. Dropping non-failing units is the one error that deflates, and it is much rarer than the others. If your MTBF has gone up sharply and nothing about the maintenance programme changed, check the numerator before you celebrate.

9. The four data problems that make the answer wrong anyway

You can get both inputs right and still produce a number that should not be acted on. These are the four issues I raise most often, and none of them is fixable by recalculating more carefully.

Small failure counts. MTBF is a mean, and a mean computed from a handful of observations is extremely unstable. Worked example one had six failures. If a seventh had happened in December, MTBF would have dropped from 700 to 600 hours, a 14 per cent swing from one event. Report that as an improvement or a deterioration quarter on quarter and you are reporting noise. With three failures the instability is worse still, and with one failure you have not measured a mean at all, you have measured one interval. My rule of thumb is that I will not draw a trend conclusion from a single asset's MTBF unless the failure count is well into double figures, which for most individual assets means aggregating over years or aggregating across a fleet. I will not publish a threshold beyond that, because the honest statistical answer depends on the variability of your own data, not on a universal rule.

Mixed failure modes. A single MTBF figure averages every way the asset can fail. Worked example one blended bearing, seal and coupling failures into 700 hours. That average is useful for planning interruptions and useless for deciding what to do, because the three mechanisms have different causes, different detection methods and different fixes. Worse, the average is stable while the mix underneath it changes: you could eliminate bearing failures entirely and see MTBF barely move if seal failures increase. The remedy is to compute MTBF per dominant failure mode as well as per asset, which requires the failure coding discipline mentioned earlier and is the point at which reliability analysis stops being a report and starts being engineering. For where that leads, see modelling equipment failure from RUL to FMEA.

Censored data. Every unit that is still running at the end of your window has an incomplete observation: it has accumulated operating time without yet failing, and you do not know how much more it would have accumulated. The simple MTBF formula handles this by throwing the partial hours into the numerator, which is a reasonable and conservative approximation when most units have failed at least once, and an increasingly poor one when most have not. In the extreme case, a fleet of new assets with zero failures has an undefined MTBF, because the denominator is zero. Dividing by zero is not a result, and the correct answer to "what is the MTBF of this new fleet" is "we do not have enough failure data yet", not a very large number. Proper treatment of censored observations needs survival analysis rather than a ratio, and that is a reasonable thing to bring in a statistician for on high-consequence assets.

Dissimilar assets aggregated. The temptation to compute one MTBF for "the chillers" or "the pumps" is strong, because that is how the asset register is grouped and how management wants to see it. If those pumps span three manufacturers, four sizes, two duties and fifteen years of age, the aggregate mean describes a population that does not exist. It will move because the mix changed rather than because reliability changed, and it cannot support any decision about any individual machine. Aggregate only across units that are genuinely comparable in model, size, duty and operating environment, and if that leaves you with populations of two or three, accept that you have a small-sample problem rather than hiding it inside a bigger group.

10. How MTBF relates to failure rate

The relationship is simple arithmetic, but it carries an assumption that is easy to lose and important to keep.

Under an assumption of constant failure rate, failure rate is the reciprocal of MTBF. Write the failure rate as the Greek lambda and the relationship is lambda equals one divided by MTBF, and equivalently MTBF equals one divided by lambda. Using the illustrative 700 hour figure from worked example one:

Expressing it per thousand hours is usually more readable than a small decimal, and it makes the comparison between assets easier to discuss in a review meeting. The conversion is just a scale factor and introduces no new assumption.

The assumption, though, is the thing to be careful about. Reciprocity holds when the failure rate is constant over the period of interest, which in reliability terms means the item is neither in early-life infant mortality nor in end-of-life wear-out. That is a real condition, not a formality, and it is precisely the condition that often fails on maintained plant: a newly overhauled machine frequently shows elevated early failures, and an asset approaching end of life shows a rising rate. When the rate is not constant, a single MTBF and a single reciprocal failure rate are both averages over a changing quantity, and neither describes the risk at the moment you are asking about.

So state the assumption whenever you publish a failure rate derived from MTBF. "Failure rate of about 1.43 per 1,000 operating hours, assuming a constant failure rate over the observation window" is an honest sentence. The bare number is not. For the calculation from the other direction, and for the cases where you should compute failure rate directly rather than inverting an MTBF, see the failure rate formula. For why the constant-rate assumption breaks down and what the shape of the rate curve actually looks like over an asset's life, that is the subject of the bathtub curve, and I will not duplicate it here.

11. Using the result correctly

Once you have a defensible number, here is what I would and would not do with it.

• Do compare it against your own baseline. MTBF is at its most useful as a trend on one asset or fleet, computed the same way every period. The direction of travel is the signal. There is no credible universal MTBF benchmark for any equipment class, and any figure presented as one should be treated as marketing rather than data. Set your targets against your own measured baseline.
• Do publish it with its inputs attached. Every MTBF figure should travel with its operating hours, its failure count, its window and its population definition. A bare MTBF number in a slide deck cannot be audited and will eventually be challenged in a meeting where you cannot reconstruct it.
• Do use it to set inspection and PM intervals, carefully. An interval set at some fraction of MTBF is a defensible starting point for a time-based task, provided the failure mode actually is age related. If it is not age related, no interval derived from MTBF will help, which is the argument reliability-centred maintenance exists to make.
• Do pair it with a repair-time metric. MTBF tells you how often; it says nothing about how long you are down. Pair it with MTTR, and note that MTTR has its own boundary dispute about whether the clock includes waiting for parts. Availability needs both, and availability feeds into OEE if you are working in a production context.
• Do not read it as a lifetime or a warranty. An MTBF of 700 hours does not mean the machine will run 700 hours and then fail, and it does not mean it is unlikely to fail before then. That misreading is common enough that the MTBF explainer is built around demolishing it.
• Do not use it to compare two organisations. Two sites with different failure definitions, different operating-time sources and different asset mixes cannot be compared on MTBF, and attempting it produces league tables that reward loose failure coding.

The practical discipline is one page: a written definition of a failure for your organisation, a named source for operating hours per asset class, a stated observation window, and a rule for aggregating populations. Write that page once, get operations and maintenance to agree it, and your MTBF becomes comparable. Skip it and every quarter's number will be argued about instead of acted on.

The idea to walk away with

MTBF is total operating time divided by number of failures, and the formula has never been the difficulty. The difficulty is that operating time is not calendar time, a failure is not a work order, partial exposure must be pro-rated, and units that have not failed still contribute their hours. Get those four things right and you have a number you can defend, trend and act on. Get any of them wrong, and the error will almost always flatter the equipment, silently, in a figure that looks entirely plausible.

Then hold the result at the right confidence. On a single asset with a handful of failures, MTBF is a noisy estimate that should not be trended quarter to quarter. Across a genuinely comparable fleet with a decent failure count, it becomes a reliable operational signal. Knowing which of those two situations you are in is more valuable than any refinement of the arithmetic.

Final thoughts

If you are setting this up for the first time, I would work in this order. Write the failure definition before you write the query. Find out where operating hours genuinely come from for each asset class, and mark the classes where you are assuming rather than measuring. Compute MTBF for one comparable fleet, not for the whole register, and check the failure count is large enough to mean something. Publish the inputs alongside the result. Only then start trending, and only against your own baseline.

That sequence sounds slow next to a report that can be built in an afternoon, and it is. The difference is that the slow version produces a number the maintenance manager and the operations manager will both accept, which is the only version that ever changes a decision.

Related reading: MTBF explained: what it is and is not, MTTR formula and calculation, MTTF formula and examples, Failure rate formula and calculation, The bathtub curve explained, Reliability metrics: MTBF, MTTR and availability, OEE formula: availability, performance, quality.