MTTR is commonly used for mean time to repair or mean time to restore. Before calculating it, state exactly when the clock starts and stops. Hands-on repair time and elapsed time until service returns answer different questions.
Formula and example
Mean duration = total qualifying duration ÷ completed qualifying events.
Suppose three completed outages lasted 1, 2 and 9 hours from loss of service to verified restoration. Mean restoration time is 12 ÷ 3 = 4 hours. The median is 2 hours. Retain both the individual durations and the average: the nine-hour event deserves investigation and may dominate a small sample.
If technicians recorded only 3 hours of hands-on labor across those outages, 3 ÷ 3 = 1 hour of labor per event. Calling both results “MTTR” without a definition creates an apparent disagreement where the teams are simply measuring different clocks.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Decide what the clock includes
Use a short metric contract that specifies the asset population, reporting window, qualifying event and timestamps. For elapsed restoration, record the time service was lost and the time required operation was verified. For hands-on repair, use labor entries and make clear how simultaneous technicians are counted. Two people working for one hour contribute two labor-hours but only one elapsed hour.
Record waiting for diagnosis, access, parts, permits or specialist support separately if your process can capture it consistently. This makes the next decision concrete: a spare-parts delay needs a different response from repeated diagnosis or rework.
Open outages and boundary cases
An outage still in progress has no completed restoration duration. Show its current age and owner separately; silently excluding it from the operational discussion can make an improving average hide a serious active incident. State whether your report selects events by start date, end date or overlap with the reporting window.
If no qualifying events were completed, display unavailable rather than zero. A negative duration indicates a timestamp problem. Check time zones, daylight-saving transitions, missing end times and duplicate outage records before publishing a trend.
Use MTTR with reliability and production data
MTBF concerns operating time per failure. MTTR concerns the declared repair or restoration duration. OEE measures effective good production during a planned window. One can improve while another deteriorates.
For example, a rapid temporary repair may reduce restoration time while increasing repeat failures. Review recurrence and verification with the repair duration. A fast close button is not evidence of a safe or durable repair.
AI-generated editorial illustration; not a customer photograph or product screenshot.
A weekly repair-delay review
- Open the longest completed outages and all active outages.
- Check start and end evidence with the responsible operator.
- Separate diagnosis, access, parts, hands-on work and verification where known.
- Choose one avoidable delay and assign an action with a due date.
- Compare the next observation window using the same definition.
Avoid universal “good MTTR” targets across different equipment and duties. A critical production line, a standby generator and a room fixture have different consequences, access constraints and restoration tests. Use your own baseline and service requirements.
What PreventiveHQ records
Work orders support labor, downtime, parts and verification records. The reliability report’s mean restoration metric uses completed unplanned downtime records starting within the selected window. It is not a stopwatch of hands-on wrench time and does not establish that every failure was captured.
Start with the free calculator on this page, then try the workflow. An editable checklist can define what evidence your technicians should retain. Compare the plans using the number of people who must create and complete records.
Define the event timeline before comparing teams
A repair event can contain several distinct intervals. The fault occurs, someone notices it, a request is raised, a technician responds, the condition is diagnosed, resources become available, the repair is performed and the asset is tested before returning to service. A single work-order duration can combine all of these intervals or omit several of them.
Write down which timestamps define your MTTR. A repair-focused measure might use the interval associated with repair activity. A restoration-focused measure might follow the entire loss of function until service is restored. Either can be useful when named and defined clearly. Comparing them as though they were identical produces misleading conclusions.
For a shared dashboard, put the clock definition beside the metric. Specify whether waiting for parts, permits, access, external contractors and operational testing are included. These decisions should follow the management question. A planner investigating readiness needs to see waiting time that would obscure a technician's hands-on repair-time comparison.
Avoid changing the clock definition simply because a team misses a target. If the definition needs correction, preserve the earlier method and state when the new method begins. Recalculate historical periods where the source data supports it, or clearly mark the discontinuity when it does not.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Distinguish elapsed time from labor hours
Elapsed repair duration follows the clock. Labor hours add the time contributed by people. Two technicians working together for three hours contribute six labor hours while the elapsed interval is three hours. These quantities answer different questions: one describes time until restoration, while the other helps describe the effort and cost of the work.
An illustrative job begins at 09:00 and is restored at 13:00. One technician works throughout, and a second assists from 11:00 until 13:00. The elapsed interval is four hours and the combined labor contribution is six hours. Recording six hours as the restoration duration would overstate the outage interval.
The reverse mistake can understate staffing effort. Recording only four labor hours would ignore the second technician's contribution. Keep the work-order labor entries and the event's restoration timeline distinct, then reconcile them when preparing a cost or staffing discussion.
This distinction matters when comparing interventions. Adding a second qualified technician may shorten an elapsed repair without reducing total labor. That could still be worthwhile where restoration time has a substantial operational consequence. Evaluate the actual tradeoff instead of treating a lower duration as automatic labor savings.
Record delays in categories that lead to action
A delay category should identify a process the team can investigate. Waiting for a spare part, waiting for equipment access, waiting for specialist support and repeating an unsuccessful repair point toward different improvements. “Other” may be necessary for exceptions, but a large unexamined “other” category limits the value of the analysis.
Use a manageable set of categories and define them with examples. If people interpret “waiting” differently, similar events will move between categories according to who enters the record. Review ambiguous cases with the team and refine the definitions. Do not add dozens of categories before understanding the decisions they are supposed to support.
Preserve overlaps when they matter. A job can be waiting for both access and a part during the same interval. Adding both durations together can exceed the actual outage. For a simple elapsed-time decomposition, agree how overlapping intervals are represented. For a resource analysis, it may be appropriate to retain separate constraints while avoiding a claim that they sum to total downtime.
The goal is to expose a practical improvement. Repeated parts delays might lead to a review of stock policy or supplier lead time. Repeated access delays might justify better coordination with operations. Those are hypotheses to test against the records, not conclusions that follow automatically from a category label.
Inspect the distribution, not just the average
An average can conceal a small number of very long events. If most repairs are short but one requires an unavailable component, the arithmetic mean can rise sharply. That may be exactly the risk management needs to see, but it should not be mistaken for the duration of a typical ordinary repair.
Show the event count and a simple list or distribution of durations. A median can describe the middle observation, while the longest events identify exceptional restoration risks. These views complement the mean rather than replacing the need to understand what happened.
For an illustrative group of durations of one, one, two and twelve hours, the mean is four hours and the median is one and a half hours. Neither number alone explains the twelve-hour event. The useful review asks whether that event involved a foreseeable parts constraint, an unusual failure mode or a data-entry mistake.
Do not remove long events solely to improve the result. Exclusions need an explicit rule tied to the metric's scope. If a major rebuild is reported separately from ordinary corrective repairs, explain the classification and retain it in the appropriate record. An inconvenient event should not disappear from operational visibility.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Handle open repairs without making them invisible
An unresolved repair has no final restoration duration. A report limited to completed events may therefore look better while the oldest and most difficult jobs remain open. This is a reporting limitation that needs a companion view, not a reason to invent an end time.
Show open-event age alongside completed-event MTTR. Include the number of unresolved events, their current ages and the reason each remains open. A supervisor can then see whether apparently improved completed-repair performance coincides with a growing unresolved backlog.
Be careful around reporting boundaries. A job completed this month may have started last month. Decide whether the summary groups events by completion date, failure date or another rule. The selected rule affects which durations enter each period and should be stable enough for the trend to be interpreted.
When an event is reopened, retain the explanation. A premature administrative closure is different from a confirmed restoration followed by a new failure. If those situations are treated interchangeably, both MTTR and the failure count can become distorted. Review the actual functional history before editing the reporting classification.
Compare similar repair populations
A team repairing small replaceable components should not be ranked directly against a team restoring complex systems using one unsegmented average. Differences in asset type, fault complexity, access and operating context can dominate the result. Segment the observations enough to support the question you are asking.
Start with a small number of meaningful groups. These might follow asset family, failure mode or restoration pathway. Keep the event counts visible because excessive segmentation creates groups too small to interpret. The aim is a defensible comparison, not a dashboard with a separate category for every job.
Consider changes in work mix over time. If simple jobs are increasingly resolved before a formal ticket is created, the remaining recorded repairs may look slower even though the overall process improved. Conversely, a month with many small repairs can lower the average while difficult outages remain unchanged.
Use the same inclusion rules when evaluating a process change. If a new parts policy is intended to reduce a particular waiting interval, examine that interval and the relevant events. A whole-site average may conceal the effect or attribute unrelated changes to the intervention.
Investigate a long event from source records
Select one consequential restoration event and reconstruct its timeline. Compare the reported fault time, first response, diagnosis, resource readiness, repair activity and return-to-service evidence. Note where the record is uncertain. A timeline with a clearly identified gap is more useful than a complete-looking sequence filled with assumptions.
Ask what information was available at each decision point. A diagnosis that seems obvious afterward may not have been supported by the initial symptoms. This helps distinguish a training need from an information or equipment-access problem. The review should produce a better process, not an unsupported judgment about individual effort.
Separate necessary work from avoidable delay. Testing can be essential to establish that the required function has been restored. Removing that step to achieve a shorter number would undermine the purpose of maintenance. Investigate whether the right test and resources were prepared, rather than assuming every minute after the physical repair is waste.
Assign a specific follow-up with an owner. Examples include correcting a parts cross-reference, improving the fault report, preparing an approved diagnostic guide or arranging specialist coverage. Track whether that action was completed and whether later comparable events reveal the same constraint.
AI-generated editorial illustration; not a customer photograph or product screenshot.
Connect repair time with reliability and consequences
MTTR describes a duration under a stated convention. It does not say how often failures occur or how serious their consequences are. A quickly repaired asset that fails repeatedly may still create substantial disruption. A rarely failing asset with a difficult restoration may require a different strategy, such as contingency planning or a reviewed spare arrangement.
Read MTTR with the event frequency, operating exposure and downtime context. Keep planned work separate where the question concerns unplanned failures. A planned overhaul may be long by design and should not automatically be treated as poor corrective-repair performance.
Availability formulas also depend on their assumptions. A simplified relationship between mean up and down times is not a substitute for measuring the actual operating calendar, exclusions and required service. When using a reliability model for an engineering decision, document the model and obtain the appropriate specialist review.
The practical benefit of the combined view is prioritization. It can help a team distinguish frequent minor interruptions from rare events that are hard to restore. Neither category should be judged solely by one ratio; the consequences and feasible improvements determine where effort is justified.
Use a repeatable weekly review
Prepare a short review pack with completed-event durations, unresolved-event ages, delay categories and links to the underlying work. Choose a small number of events that could change a maintenance decision. Reviewing every record in equal detail can consume time without improving understanding.
Start by checking data quality. Look for negative durations, impossible timestamp order, missing restoration evidence and labor hours mistakenly entered as elapsed time. Correct the record through the supported process and preserve the reason for material changes. Do not silently overwrite the source to make a report consistent.
Then review the operational constraints. Ask which delays recurred, which follow-ups from the previous review were completed and whether the evidence supports a change in planning, parts or procedure. Keep hypotheses distinct from demonstrated improvements.
Close the review with a named action and a defined observation to revisit. For example, confirm whether a corrected spare-part reference eliminates the same lookup delay in later comparable repairs. This turns MTTR from a target that people can game into a measurement that helps the maintenance process learn.
Prepare the record for a management decision
A useful management summary should identify the measurement convention, event population, period and sample size before presenting the average. Include unresolved-event ages and the main data limitations. This gives the reader enough context to distinguish a repair-process issue from a reporting change or a different mix of work.
State the proposed decision separately from the measurement. If the team recommends stocking a spare, show which events involved that part, how the waiting interval was established and what other constraints would remain. A lower hypothetical MTTR is not the same as demonstrated savings, and the inventory decision has its own costs and risks.
If the proposal involves training, explain the observed diagnostic or execution gap rather than attributing all long repairs to technician performance. If it involves contractor support, distinguish response availability from the time needed for the physical restoration. These distinctions help the budget owner assess the intervention that is actually being proposed.
After an approved change, keep the same reporting rules where practical and review comparable later events. Document other changes that could affect the result, including equipment modifications or a changed production schedule. The objective is a credible learning record, not a retrospective explanation that assigns every improvement to the latest project.
AI-generated editorial illustration; not a customer photograph or product screenshot.