Mean Time to Repair: Calculate MTTR and Cut Lost Time

Home » Resources » Mean Time to Repair: Calculate MTTR and Cut Lost Time

Estimated reading time: 11 minutes

Mean time to repair (MTTR) is the average duration of a defined repair or restoration process after equipment fails. Calculate it by adding the durations for a comparable set of completed events and dividing by the number of those events:

MTTR = total repair or restoration time ÷ number of completed events

The definition of “time” matters as much as the division. A component might take 40 minutes to replace while the machine remains unavailable for three hours. A useful report makes that difference visible, so maintenance can improve the right part of the process and production can plan around the capacity it actually has.

MTTR helps you understand previous failures. It does not tell you when the fault happening now will be fixed. That live return-to-service assumption needs maintenance’s current assessment, and it needs to reach the production schedule when it changes. SkyPlanner carries the updated machine availability into a shared schedule, so you can see the effect on customer orders without rebuilding every connected queue by hand.

First, decide which clock your MTTR measures

MTTR is used for mean time to repair, recovery and restoration, but those labels do not automatically describe identical intervals. The IEC’s dependability vocabulary uses mean time to restoration for MTTR. A report that counts only active repair work answers a narrower question than one that includes the wait for a technician or spare part.

For the worked manufacturing report in this guide, MTTR measures elapsed time from equipment failure to verified availability for production. The clock continues through response delays, diagnosis, waiting, repair, testing and any required release before the machine is available again. We record active repair time separately.

Write that rule above the report, together with the equipment boundary and reporting period. If your company, contract or reporting standard specifies another interval, use that definition and label it clearly. Do not compare its number with this one until the boundaries match.

A three-hour interruption can contain much less active repair

Imagine a machining centre that fails at 08:00 and is released as available for production at 11:00. Its event record separates the following stages:

Stage	Time interval	Duration
Waiting for the maintenance response	08:00–08:30	30 minutes
Diagnosis	08:30–08:50	20 minutes
Waiting for the required part	08:50–09:50	60 minutes
Physical repair	09:50–10:30	40 minutes
Functional testing	10:30–10:40	10 minutes
Required production-release checks	10:40–11:00	20 minutes
Total elapsed restoration time	08:00–11:00	180 minutes

For this example, the separate active-repair measure includes diagnosis, physical repair and functional testing: 20 + 40 + 10 = 70 minutes. The elapsed restoration duration is 180 minutes. Neither figure is wrong; they answer different questions.

The distinction tells you where to act. Improving the 40-minute component replacement will not remove the hour spent waiting for the part. Conversely, better parts availability will not solve a difficult diagnosis.

These stages are consecutive in the example. In a real event, some activities may overlap. Count elapsed time once: two technicians working together for 40 minutes do not create an 80-minute interruption. Labour-hours can be useful for maintenance cost analysis, but they are not interchangeable with elapsed machine time.

Keep unrelated losses outside the event

The event ends when the machine meets the agreed return-to-service condition, not when someone closes the work order later. If it is available at 11:00 but the next order has no material until noon, that extra hour is a material delay, not another hour of restoration.

Likewise, planned servicing, a normal changeover and waiting for an operator are not automatically corrective repairs. Record those losses where they belong rather than putting every stopped minute into MTTR. This report measures restoration after the defined equipment failure, not all downtime in the factory.

Choose a matched set of completed events

Start with one machine, or a group with genuinely comparable equipment and failure types. A small sensor replacement and a major rebuild may both be valid events, but averaging them without showing the mix can hide the problem you need to solve.

For a monthly report, one workable rule is to include restorations completed during the month, using each event’s full duration even if it began in the previous month. The denominator is the number of those completed events, not every fault raised during the month or every maintenance work-order line.

Apply the same rule each month and retain the underlying records. In particular:

• Use one event identifier for one unresolved failure. Several alarms, technicians or work-order tasks do not necessarily mean several restorations.
• Keep incomplete events visible. A repair still open at month-end has no final restoration duration. Show its current age and status separately; do not treat it as a completed zero-hour repair.
• Check the timestamps. Administrative entry times are not necessarily failure, response or restoration times. If the failure time is unknown, identify the detection timestamp you actually have rather than inventing an earlier one.
• Keep exclusions explicit. Explain missing timestamps, cancelled records and any event class outside the calculation. Do not remove a long valid repair merely because it makes the average look worse.

A completed-event report can look unusually favourable while a long breakdown remains open. That is why the open-event list belongs beside the average. If you instead select failures that began in the period, follow that cohort through to restoration and explain how unfinished events are handled. Do not silently switch between the two methods.

MTTR calculation example

Imagine four completed restorations on the same machine during the reporting month. Each event follows the elapsed-time rule above. The active-repair column is retained to explain the difference, not added to elapsed time.

Completed event	Elapsed failure-to-availability time	Active repair time
A	90 minutes	60 minutes
B: the 08:00–11:00 example	180 minutes	70 minutes
C	150 minutes	110 minutes
D	420 minutes	240 minutes
Total	840 minutes	480 minutes

The main calculation is:

Elapsed-restoration MTTR = 840 minutes ÷ 4 events = 210 minutes, or 3.5 hours.

The separate mean active repair time is:

480 minutes ÷ 4 events = 120 minutes, or 2 hours.

Reporting “MTTR: 2 hours” without the narrower active-time label would understate the measured elapsed restoration time in this example. Reporting 3.5 hours without its definition would leave another reader guessing what you included.

Keep units consistent before adding durations. Ninety minutes is 1.5 hours, not 0.90 hours. If no qualifying restorations were completed, there is no observed mean for that cohort; report the event count as zero and the mean as not available, rather than a zero-minute MTTR.

For a group-level result, add the included event durations and divide by their combined event count. Do not simply average machine-level means when the machines have different numbers of repairs. Keep machine and failure-type breakdowns available so the pooled figure does not hide a severe local issue.

What does a good MTTR look like?

A good result is one that improves a meaningful, consistently measured restoration process without compromising the required outcome. There is no single target in hours that makes sense for every production asset and failure type.

Compare your machine with its own baseline under similar conditions. Check whether the event mix, shift coverage, maintenance method or reporting rule changed before attributing a lower average to better repair performance. A month with several simple faults can look better than a month with one complex failure even when the team works equally well.

Read the mean alongside the event count, total lost time, individual durations and the stages causing delay. In the four-event example, the elapsed durations in order are 90, 150, 180 and 420 minutes. The median is 165 minutes, while the mean is 210 minutes. That longer final event deserves investigation; it should not be deleted to make the figures agree.

MTTR also says nothing by itself about how often the machine fails. Mean time between failures, or MTBF, addresses operating time per failure for a repairable asset. Frequent short failures and rare long failures need different improvement decisions, even when their total lost time happens to be similar.

Most importantly, 3.5 hours is not a countdown for the next repair. The current fault may require a different part, specialist or verification. Use comparable history to inform the discussion, then ask maintenance for the present assessment and the next review point.

Reduce the delay that is actually keeping production unavailable

Break the longer events into their stages before choosing an action. The best improvement is not necessarily faster hands-on work; it may be removing a delay before that work can begin.

If response is slow, review how a fault reaches the responsible person and how ownership passes between shifts. A machine identifier, observed symptoms and a clear escalation route give maintenance a more useful starting point than a vague message that production has stopped.

If diagnosis dominates, make the relevant equipment information, fault history and specialist knowledge easier to reach. Review recurring faults with maintenance and engineering. Repeatedly resetting the machine may shorten individual recorded stops without resolving the cause.

If parts waiting dominates, investigate which part was needed, how it was identified and why it was unavailable. A targeted change to critical-spare availability or identification can be more useful than stocking everything. In the three-hour example, the 60-minute parts wait is an obvious question to investigate, not proof that any particular inventory policy is already justified.

If physical repair takes longest, review preparation, access, tools, instructions and the skills required for that task. If testing or release is the bottleneck, agree how the necessary people and checks will be ready. The improvement is a better-prepared return to service, not skipped verification to stop the clock earlier.

Give the selected action an owner and review subsequent comparable events. Keep both the stage duration and the full restoration time visible. A shorter repair step has limited production value if the same time simply moves into another wait, or if incomplete work causes another interruption soon afterward.

Keep the production plan current while the repair changes

Improving future restoration is one task. Protecting today’s customer commitments is another. Production cannot wait for the month-end average before deciding what should run next.

Imagine maintenance initially expects a machining centre to return at 11:00. A later assessment moves that expectation to 14:00. The historical MTTR has not changed, but the capacity available to the waiting orders has. One order still needs inspection after machining, and the alternative centre already has work for another customer.

SkyPlanner APS makes that capacity change part of the connected production schedule. Record the maintenance-reviewed unavailable period as a workstation exception. When the expected return changes, update the time range and recalculate. SkyPlanner’s scheduling AI, Arcturus, schedules affected, schedulable operations around the recorded capacity, using your configured resources, operation dependencies, priorities and locks. The Gantt shows the resulting sequence.

For the 14:00 return, review whether the waiting machining work still leaves enough time for inspection and delivery. If a suitable alternative can take an operation, review the existing commitments on that resource too. Work that has already started needs its own restart decision; recalculating the waiting queue is not a substitute for confirming the interrupted job’s state.

The benefit is less manual reconstruction of interdependent queues and a clearer basis for delivery decisions. Maintenance owns the current restoration assessment. You decide production priorities. Arcturus handles the scheduling calculation across the connected work, instead of leaving you to repair each machine’s list separately.

That is the reason to choose SkyPlanner alongside your repair-improvement work: a revised availability assumption reaches the orders and downstream operations it affects. If uncertainty remains, agree when to review the assumption again and keep the schedule current as better information arrives.

See the delivery effect of one extended breakdown

A useful MTTR report tells you what was measured, which events produced the average and where improvement should start. A useful production plan tells you what to do while the current repair takes its own course. Connecting those decisions prevents a sound maintenance analysis from ending as an isolated monthly number.

SkyPlanner integrates with any ERP or MES through its open REST API, so connected scheduling can build on your existing order and production information.

Book a SkyPlanner demo with one recent breakdown, its revised return-to-service assumption and the customer orders passing through that resource. Ask to see which waiting operations move, what happens downstream and which delivery promises need attention. If you prefer to explore first, try SkyPlanner with demo data and see how a capacity change reshapes the schedule.