MTTR Formula: How to Calculate MTTR With Examples

Arguments about MTTR are commonly presented as a disagreement about performance when they are actually a disagreement about arithmetic boundaries. One side has calculated hands-on repair hours. The other has calculated the time the asset was unavailable to operations. Both have used the same formula, pulled from the same system, and arrived at numbers that are not remotely comparable. Neither is wrong and neither is lying. They have simply never written down which pair of timestamps their MTTR uses. This guide is about closing that gap: how to calculate MTTR so that the number means something specific, survives an audit, and points at a problem you can actually fix.

The message up front: the MTTR formula is total repair time divided by number of repairs. That is settled and uncontroversial. What is not settled is the definition of "repair time", and that single choice moves the answer far more than any improvement programme ever will. Calculate MTTR as a decomposed set of intervals rather than a single headline figure, and it stops being a scoreboard and becomes a diagnostic. If you want the concept, the vocabulary and the improvement levers rather than the calculation mechanics, start with the companion piece on what MTTR means and how to improve it, which owns that ground. This page stays on how to compute it correctly.

1. The MTTR formula, and why it is the easy part

Start with the arithmetic, because it genuinely is simple:

If five corrective jobs on a chiller consumed 20 hours of repair time between them, MTTR is 4 hours. No weighting, no adjustment for severity. It is a plain arithmetic mean, which is why it is so easy to compute wrongly.

Two things about that formula are worth pinning down before you go further. First, the denominator counts repairs, not assets, not work orders and not incidents. Those four things diverge more often than people expect, and section 7 deals with the divergence. Second, the numerator is a sum of durations, and a duration is always the difference between two timestamps. Which two is the entire subject of this article.

A formal vocabulary for this terminology does exist. IEC 60050-192:2015, Part 192 of the International Electrotechnical Vocabulary, covering dependability, is the formal home of MTBF and MTTR terms, and it supersedes the 1990 edition numbered IEC 60050-191, so citations to 60050-191 are out of date. I am not going to reproduce its definitions here, and you should be sceptical of any blog that does, because the wording circulating online is mostly secondhand paraphrase. The useful and honest observation is this: a formal vocabulary exists, and industry practice still disagrees about which clock starts and stops. The vocabulary did not settle the argument, because the argument is not really about words, it is about which timestamps a given organisation happens to record. You can browse the IEC terminology through Electropedia .

The sibling calculations follow the same pattern and have the same boundary problem in a different place: see how to calculate MTBF for the operating-time side of the ledger, and the failure rate formula for its reciprocal.

2. The candidate clocks inside a single incident

Take one failure and walk it forward event by event. A well-configured CMMS or EAM can stamp most of the following, and a poorly configured one stamps two or three and leaves the rest to guesswork:

• Failure occurred: the moment the asset stopped performing its function. Frequently unknown. Sometimes reconstructable from a trend, a meter reading or an alarm history, often only estimated.
• Failure detected: when a human or a system first became aware. A BMS or SCADA alarm stamps this precisely. A tenant noticing a warm office does not.
• Notified: when the responsible maintenance function was told. On a night shift with no on-site cover this can be hours after detection.
• Work order raised: the administrative birth of the record. This is the earliest timestamp most organisations can actually trust, which is exactly why so many MTTR definitions quietly start here.
• Technician assigned: planning and dispatch complete.
• Technician on site: mobilisation and travel done. On a multi-site portfolio this interval is substantial.
• Diagnosis complete: the fault is understood and the required parts and permits are known. Rarely stamped, and its absence is a real loss, because it is the boundary between investigation and execution.
• Parts available: the spare is physically in the technician's hands. Not the requisition date, not the goods receipt date at the central store.
• Repair complete: the physical work is finished.
• Tested: function verified against an acceptance criterion.
• Handed back: operations formally accepts the asset back into service, permits are cancelled, isolations removed.

That is eleven events and therefore fifty-five possible pairs. In practice five or six pairs are in common use, and each of them is a defensible metric with a different name and a different owner. The failure is not in choosing one. The failure is in choosing one silently.

3. The candidate pairs: what each measures and what it hides

Here is the same set laid out as choices, with the honest cost of each. The names in the first column are the ones I would use in a metric definition document, because they are harder to confuse than four different things all called MTTR.

Read down the third column and a pattern emerges. Every narrow pair hides a delay that belongs to somebody other than the maintenance crew, and every wide pair loads the crew with delays they do not control. That tension is why a single headline MTTR is structurally incapable of being fair, and it is the argument for the decomposed calculation in section 5.

4. One incident, calculated three ways

Numbers make this concrete. What follows is an illustrative example I have constructed for this article. The asset, the times and the sequence are hypothetical, chosen to be typical of a chilled water pump failure on an out-of-hours shift in a building with BMS monitoring and an on-call contractor. No client data is involved and none of the figures should be read as a benchmark.

The event log for the incident:

Now apply three entirely legitimate definitions to that one incident.

Same failure. Same data. 2.67, 10.83 and 16.10 hours. Method A is six times smaller than method C, and if two parties to a contract are each quoting their preferred method in good faith, no amount of goodwill will reconcile them. This is illustrative arithmetic, not a claim about typical ratios, but the shape of it matches what I see whenever I open a real corrective history: the narrow definitions are dramatically smaller, and the gap is almost entirely waiting.

5. The decomposed calculation, which is the only actionable one

Here is the argument of this article in one section. A single MTTR number tells you the size of a problem and nothing about its location. Decompose the same interval and it tells you where to go. Using the illustrative incident above, the 16.10 hours breaks down as follows:

Look at what the decomposition tells you that the headline never could. Wrench time is 2.67 hours out of 16.10, roughly a sixth of the outage. The two largest components are waiting for parts at 5.50 hours and notification delay at 3.75 hours, and together they account for well over half the downtime. A programme to make technicians faster would address the smallest block. A programme to fix out-of-hours alarm escalation and spares availability would address the largest two, and neither of those is a maintenance execution problem.

This is why I argue the decomposed calculation is the only actionable one. A headline MTTR that is trending upward prompts the question "why are repairs taking longer", which is usually the wrong question. A decomposed MTTR shows which component is growing, and that is a question with an owner attached. If the parts-waiting column is expanding, the conversation belongs with MRO inventory and critical spares holding, not with the crew.

The minimum viable decomposition, if eleven timestamps is unrealistic for your maturity, is three buckets: response (from detection or notification to technician on site), waiting (any interval where nobody was working on the asset because something was missing: a part, a permit, an isolation, a production window, a specialist), and wrench time (hands actually on the asset). Three numbers instead of one, and the diagnostic value is most of the way there.

One note on permits, because they are a common and frequently underestimated waiting component. Waiting for a permit to work is legitimate waiting time and should be captured as such rather than buried in repair duration. Permit-to-work practice is jurisdictional and there is no international standard specifying a PTW system; the widely used reference is UK HSE guidance HSG250, which is guidance rather than law and was written for the petroleum, chemical and allied industries: HSE HSG250 . For how the permit lifecycle is wired into the work order so the clock is captured rather than estimated, see the permit to work guide.

6. What to exclude from the calculation, and why

Every duration you sum into the numerator has to have earned its place. Three categories should be excluded, and getting these wrong is the second most common calculation error after the timestamp choice.

• Planned work. Preventive maintenance, statutory inspections, planned overhauls and shutdown work are not repairs. Including them does two things, both bad: it dilutes the mean with work whose duration was chosen in advance, and it creates a perverse incentive where doing more short PM tasks improves your MTTR. If your MTTR query filters on work order type, check that it filters on corrective and unplanned, not merely on "closed".
• Deferred corrective work. A corrective job that was correctly identified, assessed as non-urgent and scheduled into a future window is real work, but the elapsed time between raising and executing it is a planning decision, not a restoration delay. Leaving deferred correctives in the calculation is one of the fastest ways to produce an MTTR in the hundreds of hours and a report nobody believes. Deferred work belongs in backlog reporting, where its age is the point: see maintenance backlog and downtime tracking.
• Incidents where the asset was not actually down. A noisy bearing repaired during a running-hours window, a redundant pump swapped while its twin carried the load, a minor defect fixed without interrupting function. These are corrective jobs and they are not downtime events. If your MTTR is meant to be an availability input, including them corrupts it. If it is meant to be a maintainability measure of repair effort, they may legitimately belong. Decide which metric you are building and filter accordingly.

Two exclusions I would not make, because they are usually attempts to flatter the number. Do not exclude an incident because the delay was somebody else's fault; decompose it instead so the delay is visible and attributed. And do not exclude outliers without publishing the rule you used and the count you removed. A silently trimmed distribution is an edited one.

7. Multiple repairs on one incident

The denominator is where quiet distortion lives. Consider three situations that all look like "one failure" to an operations manager:

• A temporary fix followed by a permanent one. The asset is restored to service with a workaround, then properly repaired in a later window. My recommendation: count one restoration event ending at the temporary fix, because that is when function returned, and raise the permanent repair as a separate corrective job excluded from MTTR as deferred work. Counting it as two repairs halves your apparent MTTR for the same outage.
• A repeat failure shortly after handback. If the asset fails again for the same cause within a short window, the first repair did not succeed. Counting two separate short repairs makes a failed intervention look like good performance. My recommendation: count them as two repairs in MTTR, because both consumed restoration effort, but track them additionally as a rework or repeat-failure rate, and never report MTTR without that companion figure. MTTR improves when repairs are done badly and quickly, and the repeat-failure rate is the only thing that catches it.
• Multiple trades on one outage. An electrical isolation, a mechanical repair and an instrument recalibration on one incident, raised as three work orders. This is one repair, not three. If your query counts work orders, you have inflated the denominator threefold and produced an MTTR a third of the true value. Count restoration events, and if your system cannot group child work orders under a parent incident, that grouping is the fix.

The general rule I would write into a definition document: the denominator counts restoration events, where a restoration event is one continuous loss of function ending when function is returned to operations. One event, however many work orders, trades or visits it took.

8. Aggregating across assets without producing a meaningless average

Once you can compute MTTR for one asset, someone will ask for it across a portfolio, and there are two ways to do that which give different answers.

Take an illustrative set of three assets over one quarter, again with figures of my own construction:

Pooled calculation (sum all downtime, divide by all events): 24.70 / 8 = 3.09 hours.
Mean of asset means ((9.75 + 1.20 + 0.80) / 3): 3.92 hours.

The pooled figure is the correct MTTR for the population, because MTTR is defined per repair and pooling weights each repair equally. The mean of means gives the lighting panel, with five trivial repairs, the same influence as the pump with two serious ones, and it is almost always reported by accident rather than on purpose. If your BI tool averages a pre-calculated per-asset MTTR column, it is producing the second number while labelling it the first.

That said, the pooled figure at portfolio level is close to useless as a management metric, and I would resist publishing it. It mixes a 16-hour pump outage with a 40-minute lamp driver swap, and the resulting 3.09 hours describes no actual repair anyone performed. My recommendation for aggregation:

• Aggregate within homogeneous groups only. One asset class, comparable criticality, comparable failure modes. MTTR for centrifugal pumps is meaningful. MTTR for "all assets" is not.
• Report the median and the spread alongside the mean. Repair durations are right-skewed, so a single long outage drags the mean. The median tells you the typical repair and the mean tells you the total burden, and the gap between them is itself informative.
• Report the event count. An MTTR computed from three events is noise. Small samples move violently and invite over-reaction.
• Segment by criticality before averaging. The MTTR that matters is on critical assets, and pooling them with non-critical work hides exactly the movement you care about. For the KPI framing, the OEE formula breakdown shows how the availability component consumes downtime figures and how sensitive it is to their definition.

9. Why MTTR is not comparable between organisations

This section exists because the question always arrives: what is a good MTTR? The honest answer is that no credible universal benchmark exists, and I am deliberately not publishing target figures here, because any number I gave you would be quoted back at somebody in a contract negotiation as though it were authoritative.

The structural reasons MTTR resists cross-organisation comparison:

• Different timestamp pairs. Section 3 showed a six-fold spread within one incident. Two organisations using different pairs are not measuring the same quantity, so comparing their figures is a category error, not a close approximation.
• Different exclusion rules. One includes deferred correctives, another excludes them. One counts non-downtime repairs, another does not.
• Different asset mixes. A portfolio of small electrical devices will show a lower MTTR than a portfolio of large rotating plant, with no difference in competence whatsoever.
• Different logistics context. A refinery with a critical-spares store on site and a remote site relying on a three-day parts run cannot produce comparable numbers even with identical crews and identical assets.
• Different denominators. Section 7 showed how counting work orders instead of restoration events can shift the result by a factor of three.
• Different data quality. An organisation whose technicians close jobs promptly and stamp intervals accurately will often look worse than one with sloppy recording, because visible delay is recorded delay.

The useful comparison is always against yourself. Fix the definition, compute the baseline, decompose it, and then judge movement in each component over time on a stable asset population. A target set that way is defensible. A target lifted from an industry figure of unknown provenance is a number you will be held to without knowing what it measures.

Cross-organisation comparison is possible in one narrow circumstance: when both parties have adopted the same data taxonomy and the same event definitions deliberately. That is the premise behind structured reliability data collection standards such as ISO 14224:2016 for petroleum, petrochemical and natural gas equipment, which specifies how reliability and maintenance data should be collected and exchanged so that it can be pooled. Note that the standard is the taxonomy and format; the pooled databases built on top of it are separate proprietary products, not standards. Outside such a framework, assume incomparability.

10. Where the timestamps actually come from

Software is genuinely relevant to this calculation, not as a recommendation but as a constraint, because MTTR is only as good as the events your work order record captures. Speaking generically across the systems I have implemented and reviewed, the pattern is consistent:

• Creation and closure timestamps are automatic everywhere. This is why the least useful pair is the most widely reported.
• Status-change history is where the middle intervals live. Most enterprise systems, IBM Maximo, SAP PM, Hexagon EAM, Planon and Infor EAM among them, keep a status history table, and the mid-market tools such as Fiix, Limble, eMaint, UpKeep and MaintainX expose status transitions in varying depth. If your statuses are meaningful (assigned, travelling, on site, awaiting parts, awaiting permit, in progress, awaiting test, complete), the status history is your decomposition, already collected and usually unqueried.
• Detection timestamps come from outside the maintenance system: BMS, SCADA, an alarm historian, a help desk log. Capturing them means an integration or at minimum a disciplined manual field, and this is where most decomposition projects stall.
• Parts-available timestamps come from the issue transaction in stores, not from the requisition or the purchase order. If material issue is recorded against the work order, you have this stamp already.
• Handback usually comes from permit cancellation or an operations acceptance step, if one exists as a status rather than a signature on paper.

The practical implication is that improving your MTTR calculation is mostly a status-model design exercise rather than a reporting one. Before anybody builds the dashboard, design the statuses so that every meaningful wait has its own state, and make transitions mandatory rather than optional. A general treatment of how the work order record should be structured is in the work order software guide. Keep it generic: no product choice rescues a status model with three states.

11. The definition sheet to adopt before you report a figure

This is the artefact I would insist on before any MTTR number is published, whether internally or contractually. It is short enough to fit on one page and it forecloses every argument in this article.

• Metric name. Not "MTTR". Use the specific name: mean active repair time, mean operational downtime per event, mean response time. Reserve the bare acronym for conversation, never for a report header.
• Start timestamp. Named field, named system, and the rule for what to do when it is missing.
• End timestamp. Same, and specifically whether it is repair complete, tested, handed back or administratively closed.
• Denominator definition. Restoration events, with the grouping rule for multi-work-order incidents and the treatment of temporary fixes and repeat failures.
• Inclusions and exclusions. Work order types included, planned work excluded, deferred correctives excluded, non-downtime repairs treated explicitly.
• Decomposition. The component intervals reported alongside the total, at minimum response, waiting and wrench time.
• Aggregation rule. Pooled not mean-of-means, grouping level, and the criticality segmentation.
• Companion metrics. Repeat-failure rate, event count, median and spread. MTTR reported alone is reportable but not interpretable.
• Calendar basis. Elapsed clock hours or working hours, and if working hours, the calendar and the treatment of weekends, public holidays and shift patterns. This one choice can change the answer by more than everything else in the list.

That last point is the omission I see most often in otherwise careful definitions. An eight-hour downtime spanning a weekend is eight hours on an elapsed clock and possibly zero on a working-hours clock. For an availability input, always use elapsed clock hours.

The idea to walk away with

The MTTR formula is total repair time divided by number of repairs, and the formula was never the problem. The answer is decided by which of the eleven candidate timestamps you subtract, what you exclude, how you count events, and how you aggregate. Change any one of those and the number moves further than a year of genuine improvement work would move it. That is not a flaw to be apologised for; it is simply what happens when a single scalar is asked to summarise a chain of nine handoffs between six different functions.

So stop asking the number to do that. Compute the decomposition, publish the components, and let each interval sit with the function that owns it. Response belongs to dispatch and coverage. Waiting belongs to stores, procurement and the permit authority. Wrench time belongs to the crew. Once the number is split that way it stops being a scoreboard people defend and becomes a diagnostic people use, which is the only reason to calculate it at all.

Final thoughts

If you are starting from scratch, the sequence I would advise is short. Write the definition sheet in section 11 first, before touching a query. Compute the one interval your data genuinely supports and label it honestly. Audit your status model and find out which of the eleven timestamps you could capture with configuration rather than integration, because that is usually more of them than people assume. Add the three-bucket decomposition as soon as the statuses support it. Only then set a target, and set it against your own baseline rather than a figure from the internet.

The measure of success is not a lower MTTR. A lower MTTR is trivially achievable by narrowing the definition, and it happens without anybody intending to cheat. The measure of success is that when the number moves, you know within a minute which component moved and who to talk to. Get to that point and MTTR earns its place in the report pack. Short of it, you are publishing a figure that is precise, defensible and not about anything in particular.

Related reading: MTTR meaning and how to improve it, MTBF formula and calculation, Failure rate formula, Reliability metrics: MTBF, MTTR and availability, OEE formula breakdown, Maintenance backlog and downtime tracking, Spare parts and MRO inventory in a CMMS, Work order software for maintenance teams, Permit to work complete guide.