Reliability Metrics: MTBF, MTTR and Availability

Ask five people in a maintenance organisation to define MTTR and you will get five answers. Does the clock start when the asset failed, when the alarm was raised, when the work order was assigned, or when the technician arrived? Does it stop at the moment the repair was finished, or when the asset was handed back to operations? Does the two days spent waiting for a part count? Every one of those choices changes the number, often by a factor of three or more. And yet MTTR gets reported to boards, written into service contracts and compared against other sites as if it were a physical constant. The same looseness affects MTBF, availability and every derived figure that sits on top of them. This guide is about getting the definitions right, because in reliability metrics the definition is most of the work.

The message up front: MTBF, MTTR and availability are only meaningful relative to a written boundary definition that says what counts as a failure, when the clocks start and stop, what time is excluded and over what population the average is taken. Two organisations with identical equipment and identical performance can report availability figures ten points apart purely from definitional choices. Fix the definitions first, then trend your own numbers against themselves. Comparing raw figures across sites or against a published benchmark, without reconciling definitions, is close to meaningless.

1. Why the definitions matter more than the formulas

The formulas in this article are simple arithmetic. Anybody can divide uptime by total time. What separates a reliability metric that drives decisions from one that misleads is the boundary definition sitting underneath it: the written statement of what the numerator and denominator contain.

I have reviewed reporting packs where availability was quoted at two very different values on two pages, for the same assets over the same month. Neither figure was wrong. One excluded planned shutdowns and counted only scheduled running hours; the other counted calendar time. Nobody had documented which was which, so both circulated in parallel and every discussion about performance began with an argument about the numbers.

This is not a rounding problem. It is the single most common reason reliability metrics fail to change behaviour. Before any of the formulas below are useful, you need a metric definition document: one page per metric, stating the event that starts the clock, the event that stops it, the exclusions, the asset population and the reporting period. Without that, everything downstream is decoration.

2. MTBF vs MTTF: the distinction almost everyone blurs

This is the first place the terminology goes wrong, and it goes wrong in nearly every maintenance department I have worked with. MTBF and MTTF are not synonyms and they do not apply to the same class of item.

MTTF, mean time to failure, applies to non-repairable items. A bearing, a fuse, a sealed sensor, a lamp, a printed circuit board that gets swapped rather than fixed. The item runs, it fails once, and that is the end of its life. There is no "between" failures because each item only ever has one. MTTF is the average operating life of a population of such items.

MTBF, mean time between failures, applies to repairable systems. A pump, a chiller, a generator, a conveyor. The system fails, gets repaired, returns to service, fails again. MTBF is the average operating time between consecutive failures of the same system, and the critical detail is that it measures operating time, not calendar time, and it excludes the repair time itself. That is precisely what "between" means: between the end of one repair and the start of the next failure.

The distinction matters because the two answer different questions. MTTF describes how long a component lasts before its first and only failure, which is what you need for spares provisioning. MTBF describes how often a system interrupts production, which is what you need for availability and resourcing. Using MTBF language for a non-repairable component is usually harmless sloppiness; using MTTF thinking for a repairable system leads to the damaging error covered in section eight, the belief that the number tells you when the asset will die.

There is also MTBM, mean time between maintenance, counting all interventions including planned ones, and MTBUR, mean time between unscheduled removals, common in fleet contexts. Both are useful when the question is workload rather than reliability, but neither is interchangeable with MTBF and neither should be reported under that label.

3. MTTR and the question of what "repair" includes

MTTR is the metric most frequently gamed, usually without any dishonest intent. It happens because the acronym itself is ambiguous: the R has at least four common expansions, and each one describes a different span of time.

• Mean time to repair: strictly the hands-on time spent performing the repair. This is a maintainability measure. It reflects how easy the asset is to fix, and it deliberately excludes waiting, travel and administration. It is the narrowest definition and the one equipment designers care about.
• Mean time to recover or mean time to restore: from the failure to the asset being back in service. This includes diagnosis, waiting, travel, parts, repair and testing. It is an operational measure and it is what operations actually experiences.
• Mean time to respond: from the failure or notification to the technician arriving at the asset. This is a response measure, common in service contracts, and it says nothing about how long the fix takes.
• Mean time to resolve: often used in IT and service management to include the full incident lifecycle up to formal closure, which can extend well past the point the asset was working again.

If your contract says MTTR of four hours and does not say which of these it means, you have not agreed anything. I have seen exactly this dispute play out on facilities contracts where the provider was measuring response and the client was measuring restoration, and both were genuinely confident they were right.

The second ambiguity is the start event. Candidate start timestamps in a CMMS include: the time the failure actually occurred (often unknown), the time it was detected, the time the work request was raised, the time the work order was created, the time it was assigned, and the time work commenced. IBM Maximo, Hexagon EAM, SAP PM, Planon and the mid-market tools such as Fiix, Limble, eMaint and MaintainX all capture several of these, and unless you specify which pair forms your MTTR, different reports will pick different ones.

The third ambiguity, and the biggest one numerically, is waiting time. Waiting for a spare part, a permit to work, a production window, a specialist contractor, or the asset to cool down. On a critical rotating asset, waiting time routinely dwarfs wrench time. Excluding it makes maintenance look efficient while the asset sits dead. Including it makes the maintenance team accountable for a stores and procurement problem they do not control.

My recommendation is to measure and report both, separately. Report active repair time as the maintainability and crew-efficiency measure, and report total downtime as the operational measure, with waiting time broken out as its own component. That way a long outage driven by a missing spare shows up as a spares problem rather than being blamed on the technicians or hidden from view. For the interaction with contractual response and rectification windows, the SLA matrix design pillar covers how to define those clocks so they survive an audit.

4. MDT: mean down time, the metric that should be reported more

Mean down time is the average total time an asset is unavailable per failure event, from the moment it stopped performing its function to the moment it was returned to service and accepted by operations. It is the honest operational cousin of MTTR, and in my view it is the figure that should appear on the operations report while the narrow MTTR stays inside the maintenance function.

MDT decomposes cleanly, and the decomposition is where the improvement opportunities live:

When a site tells me its MTTR is excellent but availability is poor, the answer is almost always in the components above and below the active repair line. The crew is fast; the detection is slow and the parts are not there. You cannot see that from a single MTTR figure, which is the strongest argument for capturing the decomposition even if you only report the total. The practical requirement is timestamp discipline in the CMMS: detection, notification, assignment, arrival, work start, work finish, handback. Most systems have the fields. Most organisations populate two of them reliably. Closing that gap is unglamorous data-quality work and it is the prerequisite for every metric in this article, in the same way that consistent Problem-Cause-Action failure coding is the prerequisite for any failure-mode analysis.

5. The definitions table

This is the table I would put on page one of any reliability metrics standard. The fourth column is the one worth reading twice: it lists the error I actually encounter, not a theoretical one.

For the formal vocabulary and the underlying dependability standards, the relevant bodies are ISO and IEEE . If you are writing a metrics standard for a regulated or contractual context, align your definitions to the published terminology rather than inventing house language, because house language does not survive a change of contractor.

6. Inherent vs operational availability, and why vendors quote the first

Availability has several formal variants, and the gap between them is where most of the disappointment in equipment procurement comes from.

Inherent availability is MTBF divided by (MTBF plus MTTR). It is a property of the design, assuming corrective maintenance only, parts instantly available, skilled technicians on hand, no permits, no access constraints, no administrative delay. It is a laboratory figure, legitimately useful for comparing two designs on an equal footing. Operational availability is uptime divided by total time, with every real-world delay in the denominator. It is what your operations director experiences and what production figures reflect.

Vendors quote inherent availability because it is the highest number they can legitimately produce, and because the delays that separate it from operational availability are, arguably, your problem rather than theirs. That is a fair argument, and it is also why a datasheet availability figure should never be written into an operational target without adjustment. The same equipment in a site with a good stores function, a 24-hour crew and a clear permit process will deliver operational availability close to its inherent figure. In a site with a four-week parts lead time it will not come close, and no amount of pressure on the maintenance team changes that arithmetic.

7. A worked availability calculation: series vs redundant

Availability does not add, it multiplies. This is the single most useful piece of arithmetic in this article, because it explains why a chain of individually reliable components produces a system that is noticeably less reliable than any of them, and why redundancy is so disproportionately effective.

Take a single unit with an MTBF of 2,000 operating hours and a mean down time of 20 hours per failure event. Its availability is:

Now suppose the function requires three such units in series, meaning all three must work for the function to be delivered. A single pump, a single valve and a single control panel in one flow path is a series configuration. Availability multiplies:

Three components each at 99.01 percent give a system at 97.06 percent. Unavailability roughly tripled, from 0.99 percent to 2.94 percent: in an 8,760-hour year, the difference between about 87 hours and about 258 hours of lost function. This is why long series chains of single components are a structural reliability problem that no maintenance improvement programme fully solves.

Now take the same unit and put two of them in parallel redundancy, where either one alone can deliver the function. The system is unavailable only when both are down simultaneously, so you multiply the unavailabilities:

Unavailability falls from 0.99 percent to 0.0098 percent, a hundredfold reduction, from roughly 87 hours a year to under one hour. Redundancy on a single element buys more availability than any plausible improvement in MTBF or MTTR on that element. Here is the comparison in one place:

8. Failure rate, and the error of reading MTBF as a lifetime

Failure rate, conventionally written as lambda, is failures per unit of operating time. In the special case where the failure rate is constant, it is simply the reciprocal of MTBF, and MTBF is the reciprocal of lambda. That reciprocal relationship is the source of an enormous amount of confusion, because it only holds when the failure rate is constant, and it invites a reading of MTBF that is flatly wrong.

MTBF is not a service life and it is not a guarantee. An MTBF of 2,000 hours does not mean the asset will run for 2,000 hours and then fail. It means that across the population and period observed, there was on average one failure per 2,000 operating hours. Under a constant failure rate, the probability of surviving a full MTBF without failure is about 37 percent, so roughly two thirds of items fail before reaching their MTBF.

This matters in procurement. A datasheet MTBF of 100,000 hours does not promise eleven years of service. It is a statement about failure rate, usually derived from accelerated testing or a reliability prediction model under stated conditions that may bear little resemblance to your site. It is a comparative figure for ranking two designs, not a lifetime commitment.

It also matters for interval setting. Some organisations set PM intervals at a fraction of MTBF, which is superficially reasonable and often wrong, because it assumes the failure mode is age-related. Many are not. For the distribution detail, the bathtub curve, the Weibull shape parameter and how to tell a random failure mode from a wear-out mode, see the RUL to FMEA failure modelling pillar, which covers the statistics properly rather than repeating them here. The short version for this article: MTBF collapses the whole shape of a failure distribution into a single average, and averages hide exactly the information you need to choose a maintenance strategy. The decision about which strategy each failure mode deserves belongs to RCM analysis, not to an MTBF figure.

9. OEE and where availability sits inside it

Overall equipment effectiveness is the production world's composite metric, and it contains an availability term, which is why it belongs in this article and why it causes reconciliation arguments.

The critical detail is the denominator of the availability term: planned production time, not calendar time. Planned shutdowns, unstaffed shifts and scheduled changeovers are deliberately excluded, because OEE asks how well the equipment performed during the time it was supposed to be producing. That is a legitimate question and a different one from operational availability. So when the maintenance report and the production report show different availability figures for the same asset, both can be correct: different denominators, different exclusion rules. The mistake is to treat them as the same number and spend a meeting reconciling them. Label them differently, state the denominator on each, and let them coexist.

The other thing OEE does well is force the conversation past availability. An asset that is available but running at 70 percent of rate, or producing scrap, is not performing. The multiplication is also useful: three factors at 90 percent give an OEE of 72.9 percent, a far more honest picture of the loss than any single factor suggests. That is the same compounding logic as the series availability calculation in section seven, applied to loss categories instead of components.

10. What these metrics cannot tell you

This is the section I most want a reliability newcomer to read. The metric set is genuinely useful and it is also structurally blind to several things that matter.

• Consequence. MTBF counts failures without weighting them. Twelve nuisance failures on a car park lighting circuit and one failure of a critical process pump can contribute equally while representing wildly different risk. Availability at least weights by duration, but an hour of lost function on a trivial asset still counts the same as an hour on a critical one. Weighting requires asset criticality classification layered on top.
• Failure mode and cause. A single MTBF figure aggregates every way the asset can fail, so it cannot tell you what to fix. Nor does it say whether the cause was design, operation, maintenance quality, environment or a bad spare. Improving the number requires causal analysis the metric cannot provide.
• Whether the maintenance was any good. An asset can show good MTBF because it is barely used, or because the crew is quietly doing constant unrecorded intervention. Neither is visible in the metric.
• Near misses and degraded operation. An asset running hot, noisy and derated but not formally failed contributes nothing to MTBF and nothing to downtime, while representing real and growing risk. That is the gap condition monitoring and predictive maintenance exist to fill.
• Whether preventive work is actually being done. Availability can look fine for a long time while a PM backlog builds, until it does not. Leading indicators such as PM schedule compliance are the counterweight to these lagging metrics.

The pattern is consistent: these are lagging outcome metrics. They are excellent at detecting that something is wrong and poor at telling you what. That is their nature, not a defect, and it is why they belong in a balanced set alongside leading indicators rather than being reported alone. The KPI tree approach is how I would structure that balance, and the FM KPI framework pillar sets out a worked set for facilities operations.

11. How these numbers get gamed, and why small samples make them noisy

Gaming is rarely fraudulent. It is almost always a series of individually defensible classification choices that all happen to push the number the same way. The ones I see most often:

• Reclassifying failures as planned work. An asset taken offline "for inspection" the day before it would have failed leaves the failure count, and often leaves the availability denominator too.
• Splitting or merging events. One long outage recorded as three short work orders improves MTTR dramatically while leaving total downtime unchanged. Merging several failures into one event improves MTBF.
• Late failure timestamps and early handback timestamps. Recording the failure when the work order was raised rather than when function was lost removes the detection delay. Recording handback at repair completion rather than operational acceptance removes the testing time.
• Closing the work order before the asset is actually back. Common where closure is a KPI in its own right.
• Excluding "not our fault" downtime. Utility outage, operator error, no access, waiting for client approval. Each exclusion is arguable and the cumulative effect is large.
• Changing the asset population. Dropping the worst performers from scope, or adding new assets that have not yet had time to fail, both move MTBF with no change in performance.

Then there is the statistical problem, which is not gaming at all but is just as capable of producing a misleading picture. These metrics are averages, and averages over small samples are noisy. If an asset failed twice last year, its MTBF is calculated from two events. One additional failure, or one fewer, swings the figure by fifty percent. Reporting that as a trend, and worse, holding someone accountable for it, is reading randomness as signal.

Two practical defences. First, aggregate to the asset class rather than the individual asset where the population allows it. Thirty similar pumps generate enough failure events for a meaningful MTBF even though no single pump does. Second, lengthen the reporting window. A rolling twelve-month figure is far more stable than a monthly one, and for low-failure-rate assets even twelve months may be too short. A metric quoted to two decimal places from three events is false precision, and experienced readers will discount the whole pack when they notice it.

A related discipline: report the raw counts alongside every derived metric. Number of failures, total downtime hours, total operating hours. Anybody can then recompute your figure and see the sample size. Metrics that hide their inputs invite suspicion; metrics that show their inputs get trusted.

12. Implementation checklist: defining the metric set before you report a figure

This is the sequence I would follow when setting up or repairing a reliability metrics programme. None of it requires new software.

• Write the metric definition document. One page per metric: name, formula, start event, stop event, inclusions, exclusions, asset population, reporting period, data source fields. Signed off by maintenance, operations and the contract manager.
• Define "failure" explicitly. Loss of a stated function, not "something broke". Include partial and degraded criteria, because the ambiguous cases are where classification drift starts.
• Decide the operating-time source. Runtime meter, SCADA hours or assumed schedule. MTBF needs operating hours and most organisations quietly substitute calendar hours.
• Map the timestamps. Name the exact CMMS fields supplying each start and stop, then check on a real sample of work orders that they are populated.
• Publish the exclusion list. Every excluded downtime category, with its reason. An exclusion list that grows every quarter is a warning sign.
• Set the aggregation level. Anchor it to criticality: individual reporting for critical assets, class-level for the rest.
• Choose windows that match the failure rate. Rolling twelve months as the default, with failure counts shown alongside.
• Report MTTR and MDT separately, with the delay decomposition visible, so a spares or permit problem is not misread as a crew problem.
• Baseline before you improve. Establish the current figure under the agreed definitions first, or you will never show the initiative worked.
• Trend against yourself, not against a benchmark. Typical values for MTBF, MTTR and availability are strongly sector-specific and configuration-specific, and published benchmarks rarely disclose their boundary definitions. Your own trend under stable definitions is more informative than any external figure, and it is the only comparison you can defend.

That last point is the one most often resisted. Executives want to know how the site compares to industry. The honest answer is that without reconciling definitions, asset mix, duty cycle, operating environment and redundancy design, the comparison is not valid. What is valid, and what drives improvement, is whether your own availability is better this year than last under an unchanged definition. Offer that instead. For plant contexts where duty cycles vary widely between sites, the industrial and plant equipment PM pillar covers why cross-site comparison is particularly treacherous.

The idea to walk away with

MTBF, MTTR and availability are not measurements in the way a pressure gauge is a measurement. They are constructions, and what they construct depends on the definitions you feed them. Get the definitions written down, agreed and stable, and the set becomes one of the most useful instruments a maintenance organisation has: it shows where reliability is degrading, quantifies the cost of downtime, justifies redundancy investment, and proves whether an improvement programme worked. Leave the definitions implicit and the same metrics become a source of argument, a target for unconscious gaming, and eventually numbers nobody believes.

The compounding arithmetic in section seven is the other thing worth carrying away. Availability multiplies down a series chain and unavailability multiplies across redundancy, so the biggest availability levers are usually architectural rather than operational. When a critical function sits on a single series chain, no amount of faster repair delivers the availability that one well-designed redundant element would, and knowing that changes where you spend the capital budget.

Final thoughts

The discipline here is unfashionable. Nobody gets promoted for writing a metric definition document, and no software vendor sells one. But nearly every reliability reporting problem I have been asked to untangle came back to the same root: a number was being reported whose boundaries had never been agreed, so it meant something different to everyone who read it. Two days spent defining the terms saves years of circular argument.

If you are starting from a standing start, do three things. Define failure. Define the clocks. Show the raw counts next to every average. Do those three and your MTBF, MTTR and availability figures will be defensible, comparable over time, and worth the meeting they are discussed in. Skip them and you will have a very tidy dashboard that nobody trusts, which is the most common state of reliability reporting in the industry and the easiest one to fix.

Related reading: From RUL to FMEA: modelling equipment failure, Reliability-centred maintenance: an introduction, FM KPI framework, Building a KPI tree, PM KPIs and schedule compliance, Asset criticality classification, Failure codes: Problem, Cause, Action.