![\"MTTR](\"https:\/\/zenithsoftware.ca\/wp-content\/uploads\/2026\/09\/mttr-mean-time-to-restoration-four-clocks.png\")
The acronym does not mean what you think it means<\/h2>\n
Start with the least comfortable fact, because everything else follows from it.<\/p>\n
In the International Electrotechnical Vocabulary \u2014 IEC 60050, the reference vocabulary for this field \u2014 entry 192-07-23<\/a> defines MTTR as mean time to restoration<\/strong>, “expectation of the time to restoration”.<\/p>\n The same entry lists two alternatives, and marks them both:<\/p>\n DEPRECATED: mean time to repair Both of the things people normally mean by MTTR are formally deprecated in the vocabulary that governs the term. The entry carries a publication date of February 2015, and unlike almost every other standard in this field, you can read it for nothing<\/strong> \u2014 the IEC publishes the vocabulary free on Electropedia.<\/p>\n This is not pedantry about wording. Restoration and repair are different spans of time. Repair is the work. Restoration is everything between the equipment stopping and the equipment being available again. On most jobs that span is dominated by waiting, not working. Report one and let your reader assume the other and you are out by an order of magnitude, as the worked example below shows.<\/p>\n The meaning changed underneath the industry. In a 2017 chapter for the open-access volume System Reliability<\/em>, Jon T. Selvik and Eric P. Ford trace it plainly: “The change of the meaning of MTTR in 1999 has the engineering population still divided”<\/a> between those using “mean time to restoration” and those keeping the old definition.<\/p>\n They regard the proposal to drop MTTR in favour of unambiguous terms as an acceptable way out, while noting plainly that completing the change is difficult because the old term has such a strong position in industry. That seems right to us. We have not seen a maintenance system that implements the distinction cleanly, including ours.<\/p>\n Take a single pump failure and time it properly.<\/p>\n The pump trips at 02:10 on Tuesday<\/strong>. Nobody is in that part of the plant overnight, and an operator finds it on the morning round at 06:40<\/strong>. The work order is raised. The seal kit is not in the storeroom, and the part arrives at 14:20 on Wednesday<\/strong>. The millwright works from 14:20 to 17:50<\/strong> \u2014 three and a half hours of localising the fault, changing the seal and running a function check. The permit is closed out and the line refilled and vented. The pump is back in service at 20:20<\/strong>.<\/p>\n One event. Here are four numbers, all correct:<\/p>\n 3.5 hours<\/strong> \u2014 active repair time. Hands on the machine. The spread is twelve to one<\/strong>. And the two biggest components are not work at all: 31.7 hours waiting for a part, and 4.5 hours during which the pump was broken and nobody knew.<\/p>\n If your MTTR is 3.5 and your buyer hears 42.2, you have not shaded a number. You have described a different event.<\/p>\n Selvik and Ford break the span into four elements. The breakdown is worth internalising, because it tells you which fields your system needs. Restoration covers fault detection time; preparation and delays, meaning administrative, logistic and technical delays before work starts; active repair time; and delays after the item is repaired, mainly administrative.<\/p>\n Active repair time has its own internal structure \u2014 “the effective time needed to achieve the repair of an item”, made up of fault localisation time, fault correction time and function checkout time<\/strong>. The three activities inside our millwright’s 3.5 hours map onto those exactly: finding the fault, changing the seal, running the check.<\/p>\n Note what this means for the common shortcut of timing a job from “work started” to “work finished”. That captures element three and nothing else. It is a real number. It is not MTTR under any current definition.<\/p>\n This is where the vocabulary earns its keep, because the standards have already named most of what we measured.<\/p>\n Selvik and Ford give the composition of MRT<\/strong>, mean overall repairing time. It is mean active repair time, plus administrative delay before repair, plus logistical delay, plus technical delay, plus administrative delay after repair. Logistic delay is in, unconditionally. Run our pump through it: 3.5 + 31.7 + 2.5 = 37.7 hours<\/strong>. The third number in our list is not an arbitrary cut. It is MRT.<\/p>\n The repair-focused quantity is MART<\/strong>, mean active repair time \u2014 our 3.5 hours. And MTTRes<\/strong>, mean time to restoration, adds fault detection time on top of MRT, which gives 42.2 hours: our fourth number.<\/p>\n So three of the four clocks are named quantities, and they are 3.5, 37.7 and 42.2 hours for the same failure. The 6.0-hour figure \u2014 the one closest to what many teams actually report \u2014 is the only one with no standard name at all.<\/p>\n One correction worth making to a common claim, including one we nearly made ourselves: the three-part definition of MRT that circulates in this discussion is from ISO\/TR 12489:2013<\/strong>, not ISO 14224. And ISO 14224 does still define MTTR itself, as the expected time to achieve repair of a failed item. It has not abolished the term.<\/p>\n Every discussion of MTTR concentrates on the end of the span. The genuinely difficult end is the beginning, and almost nobody records it honestly.<\/p>\n In our pump example the failure time is 02:10 \u2014 but how does anyone know that? Three answers are common, and they give three different numbers.<\/p>\n The operator’s best guess.<\/strong> “It was running at the end of my shift.” That places the failure somewhere in an eight-hour window. In practice people round to the start of the window when they are careful, and to the moment of discovery when they are busy. The second habit deletes the entire detection delay from your data.<\/p>\n The detection time, used as the failure time.<\/strong> The commonest choice, because it is the first timestamp anybody can evidence. It is defensible so long as you say so. But it silently converts a 42.2-hour event into a 37.7-hour one, and it makes your detection performance invisible by definition. If condition monitoring or an inspection round<\/a> would have caught the fault eight hours earlier, nothing in your data will ever say so.<\/p>\n A control system timestamp.<\/strong> The only genuinely evidenced answer, and available for a minority of assets \u2014 a growing minority, but still a minority on most sites. Where you have it, use it, and accept that your MTTR will look worse than your neighbour’s \u2014 not because your maintenance is worse, but because you are counting hours they never recorded.<\/p>\n Then there is the awkward case nobody’s field structure handles: equipment that did not stop. A pump running at 60% duty. A chiller holding temperature on one of two circuits. A conveyor at reduced speed. Production is impaired, the asset is not down, and every duration-based metric has nowhere to put it. The usual outcome is that they are recorded as zero down time, which is the one answer that is certainly wrong.<\/p>\n The practical position is to record what you can evidence, label it for what it is, and keep a separate field for detection rather than folding it into the failure time. A dataset that distinguishes “failed at” from “detected at” can answer questions about inspection effectiveness later. One that conflates them has thrown that away permanently, and no amount of reporting<\/a> afterwards can reconstruct it.<\/p>\n ISO 14224 is the standard most often cited in this area, usually without anyone mentioning two things about it.<\/p>\n The first is its scope. Per ISO’s own abstract<\/a>, the standard “provides a comprehensive basis for the collection of reliability and maintenance (RM) data in a standard format for equipment in all facilities and operations within the petroleum, natural gas and petrochemical industries<\/strong>“. If you run a hospital, a school district or a food plant, the standard everyone quotes at you was not written for your industry. That does not make it useless. The data model is genuinely good and widely borrowed. But it is worth knowing before you treat the standard as binding.<\/p>\n The second is that it is sold, not published. Edition 3 was published on 16 September 2016, runs to 272 pages, and costs CHF 227. We have not bought it, so we will describe what others report of it and quote only ISO’s own public abstract.<\/p>\n What Selvik and Ford report is that ISO 14224 tries to reduce the MTTR ambiguity by pointing users toward MTTRes and MRT. It does not abolish MTTR. It also defines it, as the expected time to achieve repair of a failed item. So “the standard says stop using MTTR” is stronger than what the standard does.<\/p>\n They also flag the awkward edge, and it is the one that matters most in practice. Here is a note attached to the ISO 14224 definition, quoted at second hand because we have not opened the standard ourselves. The time spent before starting the maintenance “is dependent on access to resources, e.g., spare parts, tools, personnel, subsea intervention and support vessels.” That delay is, in their words, sometimes difficult to distinguish from delays caused by manufacturing time and transportation.<\/p>\n In plain terms: nobody has a clean rule for how much of a six-week part lead time counts as your maintenance performance rather than your supply chain’s. The standards acknowledge the problem rather than solving it. Anyone who offers you a clean rule has made one up.<\/p>\n EN 15341<\/strong> is the European maintenance KPI standard. Its abstract, as reproduced in NBS\u2019s publication index<\/a>, describes “a system for monitoring maintenance performance using key indicators covering economical, technical and organisational factors and looks at selection methodology.” The 2019 edition is withdrawn; the current text is EN 15341:2019+A1:2022. Also sold rather than published.<\/p>\n SMRP<\/strong> numbers it too, and the name it uses is instructive. In SMRP’s own 2018 metrics workshop materials, hosted publicly by PEMAC<\/a>, metric 3.5.2<\/strong> is “Mean Time to Repair or Replace<\/em>“, alongside 3.5.1 for MTBF and 2.2 for Availability. That “or Replace” is doing real work. If a pump is swapped for a spare unit rather than repaired in place, the swap still takes recordable time. A metric named only for repair invites people to leave it out. The full definitions live in SMRP’s paid Best Practices compendium; the free workshop material names the metrics without giving formulas, and we have not represented what the paid document contains.<\/p>\n MTTR does not stay in its lane. It feeds availability, and that is where a definitional slip turns into a number somebody signs.<\/p>\n The formula is usually written A = MTBF \u00f7 (MTBF + MTTR). Worth a footnote, given the subject of this page: that common rendering is itself loose, because a mean time between failures measured failure-to-failure already contains the downtime, so the denominator double-counts. The rigorous form uses mean time to failure<\/em>: A = MTTF \u00f7 (MTTF + MTTR). Selvik and Ford argue the denominator should carry MTTRes specifically. With the round numbers below it makes no arithmetic difference, but a page complaining about sloppy definitions should not be sloppy about this one.<\/p>\n Take our pump, and assume 1,000 hours mean time between failures. Same asset, same year, four MTTR definitions:<\/p>\n MTTR 3.5 h \u2192 availability 99.65%<\/strong> 3.7 percentage points<\/strong> between the most and least flattering, from a single choice nobody wrote down. That is not a rounding difference. It is the gap between a number you would put in a board pack and one that would start a capital project.<\/p>\n We would also expect the error to have a direction rather than being random, for the ordinary reason that the person choosing the definition is usually the person being measured by it. That is a prediction about incentives, not something we can show you data for.<\/p>\n There is a second problem sitting underneath the definitional one, and it survives even if you get the definition right.<\/p>\n Repair durations have a long right tail. Most jobs cluster; a few are catastrophic. The arithmetic mean \u2014 the M in MTTR \u2014 is the one summary statistic guaranteed to be dragged around by the catastrophes.<\/p>\n Nine repairs on one asset, in hours: 1.0, 1.5, 2.0, 2.0, 2.5, 3.0, 3.5, 4.0, and one gearbox failure at 41.0.<\/p>\n Mean: 6.7 hours<\/strong>. Median: 2,5 heures<\/strong>.<\/p>\n<\/blockquote>\n The mean is 2.7 times the median, and only one of the nine repairs took longer than the “average” repair<\/strong>. Quote 6.7 hours as your typical repair time and you have described none of your work. Quote 2.5 and you have hidden the gearbox.<\/p>\n Report both. The median tells a planner what to expect; the mean tells a finance director what to budget; the maximum tells a risk committee what can happen. The single number cannot do all three jobs. The mean does have one genuine claim on the job. It composes additively into availability, which the median does not. That is an argument for reporting it alongside the median, not instead of it.<\/p>\n None of this argues for abandoning the metric. It argues for four habits.<\/p>\n Record the elements, not the total.<\/strong> Capture failure time, detection time, work start, work finish and return to service as five separate stamps. Then you can compute any definition anyone asks for. If you capture a single duration, you can compute one, and you cannot convert it. Five fields is the whole engineering requirement here \u2014 and it is the same argument as keeping downtime, repair time and crew-hours as three separate numbers on the work order<\/a> rather than one.<\/p>\n Write your definition down and publish it next to the number.<\/strong> One sentence: “MTTR here means active repair time, from work start to function checkout complete, excluding logistic delay.” Any of the four is defensible. Being unable to say which one is not.<\/p>\n Decide the waiting question once, centrally, and make it visible.<\/strong> Whether waiting for a part counts is a policy. It is not a judgement for whoever happens to put the job on hold. Flag each hold reason once as counting toward repair time or not. Then show the consequence on the option at the moment somebody picks it, so the person creating the data sees what their choice does to the number.<\/p>\n Report the exclusions out loud.<\/strong> “MTTR 3.5 h; 31.7 h excluded as logistic delay” is a defensible line. “MTTR 3.5 h” is the same claim with the inconvenient half removed, and the first time somebody reconciles it against production’s downtime log, every other number you report becomes suspect too.<\/p>\n The prize for doing this is not a better-looking dashboard. It is that when a regulator, an insurer or an acquirer asks how you calculate it, the answer is a sentence rather than a meeting.<\/p>\n We did not buy ISO 14224:2016, EN 15341:2019+A1:2022, or SMRP’s Best Practices compendium. Every characterisation of ISO 14224’s contents above comes either from Selvik and Ford’s 2017 peer-reviewed chapter, which we have cited so you can check it, or from ISO’s own public abstract. One passage of ISO 14224’s body text \u2014 the note about access to resources \u2014 is quoted at second hand from Selvik and Ford, and is flagged as such where it appears. We have quoted no other standard’s body text.<\/p>\n The IEC 60050-192 entry we quote directly was read from the IEC’s own Electropedia site, entry 192-07-23, publication date February 2015.<\/p>\n We could not find a freely available authoritative source stating a target or benchmark MTTR figure for any equipment class, and we would treat any specific figure quoted without an instrument behind it as folklore. The SMRP workshop material we read names MTTR as metric 3.5.2 but gives no formula and no target.<\/p>\n The pump example is constructed to make the arithmetic checkable, not drawn from a customer. The nine repair durations are likewise illustrative.<\/p>\n Officially, mean time to restoration. IEC 60050-192 entry 192-07-23 gives that as the term for MTTR and marks both “mean time to repair” and “mean time to recovery” as deprecated. In practice the industry uses all three interchangeably, which is the source of most MTTR disputes.<\/p>\n It depends entirely on which definition you are using, and that is the honest answer. Mean time to restoration includes logistic delay; active repair time excludes it. In our worked example the difference is 3.5 hours against 42.2 hours for the same failure. Decide which you mean, write it down, and state the exclusions alongside the figure.<\/p>\n MTTRes is ISO 14224’s attempt to escape the ambiguity by naming mean time to restoration explicitly, leaving MRT for the repair-focused measure. Selvik and Ford report that ISO 14224 recommends MTTRes precisely because MTTR has become unreliable as a term.<\/p>\n Both, reported separately. Repair durations are right-skewed, so the mean is pulled upward by rare catastrophic jobs. In our nine-repair example the mean is 6.7 hours and the median 2.5, and only one repair of the nine exceeded the mean. The median describes typical work; the mean describes total burden.<\/p>\n Its stated scope is the petroleum, natural gas and petrochemical industries. Its failure-mode taxonomy and data model are widely borrowed elsewhere, and are genuinely useful. But it was not written for hospitals, schools or general manufacturing. Say so when somebody cites it as though it binds you.<\/p>\n Conventionally A = MTBF \u00f7 (MTBF + MTTR), so the definition you choose propagates straight into the availability figure. At 1,000 hours MTBF, our four MTTR definitions produce availability between 95.95% and 99.65% for the same asset \u2014 a 3.7 point spread from a wording choice.<\/p>\n Five timestamps per failure: when the equipment failed, when the failure was detected, when work started, when work finished, and when the asset returned to service. With those five you can compute any accepted definition. With a single “duration” field you can compute one and convert to none of the others.<\/p>\n Three sources carry this page. IEC’s Electropedia, for the vocabulary entry, which is free to read and which we quote verbatim. ISO’s public catalogue page for 14224:2016, for scope, edition, date, page count and price. And Selvik and Ford’s chapter “Down Time Terms and Information Used for Assessment of Equipment Reliability and Maintenance Performance”, in System Reliability<\/em> (2017), an open-access volume, for the history of the 1999 change and for what ISO 14224 recommends internally.<\/p>\n The SMRP metric numbering comes from SMRP’s own 2018 workshop material as hosted by PEMAC. Everything else is arithmetic you can redo.<\/p>\n This page is the third in a series on maintenance numbers that do not survive checking. The first asked how long Canadian law requires you to keep maintenance records<\/a>. The second worked through maintenance backlog in weeks of work<\/a>, and found that the benchmark everyone quotes has no source behind it either.<\/p>\n If you find an error, we would like to know about it.<\/p>","protected":false},"excerpt":{"rendered":" MTTR officially means mean time to restoration \u2014 and both “mean time to repair” and “mean time to recovery” are formally deprecated. One pump failure, four defensible answers, twelve to one apart.<\/p>","protected":false},"author":1,"featured_media":259172,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[12,25,24],"tags":[63,237,66,215,39],"class_list":["post-259166","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-computerised-maintenance-management-system-cmms","category-maintenance-management","category-work-order-management","tag-maintenance-management","tag-maintenance-software","tag-operational-efficiency","tag-work-order-management","tag-zenith-software"],"yoast_head":"\n\n
DEPRECATED: mean time to recovery<\/p>\n<\/blockquote>\nWhy the MTTR confusion is not your fault<\/h3>\n
Four MTTR clocks, one failure<\/h2>\n
\n
\n6.0 hours<\/strong> \u2014 active repair plus permit close-out and re-commissioning.
\n37.7 hours<\/strong> \u2014 everything from the work order being raised to the pump being available.
\n42.2 hours<\/strong> \u2014 from the moment production stopped.<\/p>\n<\/blockquote>\nWhat the standards say sits inside an MTTR<\/h3>\n
Three of the four numbers have proper names<\/h3>\n
The hardest question is when the clock starts<\/h2>\n
Equipment that did not stop, and MTTR has nowhere to put it<\/h3>\n
What ISO 14224 actually is, and who it is for<\/h2>\n
What ISO 14224 does and does not say about MTTR<\/h3>\n
The other standards, and what they cost<\/h2>\n
The definition propagates into availability<\/h2>\n
\n
\nMTTR 6.0 h \u2192 availability 99.40%<\/strong>
\nMTTR 37.7 h \u2192 availability 96.37%<\/strong>
\nMTTR 42.2 h \u2192 availability 95.95%<\/strong><\/p>\n<\/blockquote>\nThe mean is the wrong average for an MTTR<\/h2>\n
\n
How to produce an MTTR you can defend<\/h2>\n
Two habits that make an MTTR defensible<\/h3>\n
What we could not verify about MTTR<\/h2>\n
Frequently asked questions<\/h2>\n
What does MTTR stand for?<\/h3>\n
Does MTTR include waiting for parts?<\/h3>\n
What is the difference between MTTR and MTTRes?<\/h3>\n
Should I use the mean or the median for repair time?<\/h3>\n
Is ISO 14224 relevant outside oil and gas?<\/h3>\n
How does MTTR affect availability?<\/h3>\n
What should a CMMS record so MTTR can be calculated properly?<\/h3>\n
A note on sources<\/h2>\n