Mean time between repairs (MTBR) is the average operating time between repair events on an asset: MTBR = total operating time ÷ number of repairs. Unlike MTBF it counts every repair, planned, minor, and corrective, not just functional failures, so for the same asset over the same period, MTBR is usually the shorter number.
MTBR and MTBF get used interchangeably on a lot of dashboards, and that is a mistake. They answer two different questions. MTBF asks "how often does this asset break?" MTBR asks "how often does this asset need someone to stop it and touch it?" A machine can have a comfortable MTBF and a miserable MTBR, running fine between breakdowns but eating a technician's time every few days on adjustments, top-ups, and small fixes. This guide covers the calculation, the difference, why MTBR runs shorter, and when it is the metric you actually want.
How do you calculate MTBR?
Divide the asset's total operating time in a period by the number of repair events in that period. The definition of "operating time" is exactly the same as for MTBF, actual running time, with planned downtime and repair time excluded. What changes is the numerator's counterpart: a repair is any event where the asset was stopped and worked on whether or not it had failed.
Take the same filler used in our MTBF worked example: 1,000 operating hours in a quarter. It broke down 4 times, that is the MTBF count, giving 1,000 ÷ 4 = 250 hours. But it also needed four planned minor stops in that quarter, a belt swap, two adjustments, and a seal top-up, each requiring a technician to stop it and work on it. Total repair events = 8, so MTBR = 1,000 ÷ 8 = 125 hours. Same machine, same period, two honest numbers that mean different things.
What is the difference between MTBR and MTBF?
The difference is what counts as an event. MTBF only counts events where the asset could not perform its function true failures. MTBR counts every event where the asset was stopped for a repair, including planned interventions and minor fixes that never rose to the level of a failure. Because MTBR's net is wider, it captures the full maintenance load an asset places on your crew, not just its breakdown rate.
| Question | MTBF | MTBR |
|---|---|---|
| What it counts | Functional failures only | All repair events, planned and minor included |
| Question it answers | How often does it break? | How often does it need hands on it? |
| Typical size | Longer (fewer events) | Shorter (more events) |
| Best for | Reliability of the asset itself | Total maintenance burden and labor demand |
| Blind spot | Ignores frequent minor upkeep | Can penalize good preventive habits |
Neither is "more correct." They are two lenses on the same asset. Track them together and the gap between them tells its own story: a wide gap (MTBF much longer than MTBR) means the asset rarely fails but demands constant small attention, a candidate for design-out work or a better PM strategy. A narrow gap means most of your interventions are actual breakdowns, which points at root cause analysis and reliability work.
Why is MTBR usually shorter than MTBF?
Pure arithmetic: MTBR puts more events in the denominator. Every failure is a repair, but not every repair is a failure, so the repair count is always greater than or equal to the failure count, and dividing the same operating hours by a bigger number gives a smaller result. The only case where they are equal is an asset whose only interventions are unplanned breakdowns, which describes almost no real equipment.
This is exactly why plants with heavy preventive maintenance or usage-based programs should be careful reading MTBF alone. If you shift work from reactive to planned, your failure count drops and MTBF rises, good, but every planned intervention is still a repair event, so MTBR captures the true labor you are spending to keep the asset healthy. MTBR keeps you honest about the cost of reliability, not just the result.
When should you use MTBR instead of MTBF?
Use MTBR when the question is about your people and cost and MTBF when the question is about the asset's reliability.
MTBR is a favorite in rotating-equipment reliability, refineries and chemical plants track pump MTBR in months or years as a headline number, because a pump's whole cost of ownership is dominated by how often it comes off the line for repair, failure or not. Top-quartile sites run years between repairs; laggards churn the same pumps every few months. If your world is pumps seals, and bearings, MTBR is often the truer scorecard than MTBF.
What mistakes do plants make with MTBR?
Mixing repair definitions across assets. If Line A logs every seal top-up as a repair and Line B only logs teardowns, comparing their MTBR is meaningless. Fix the definition of a repair before the metric leaves one asset.
Punishing good preventive habits. MTBR falls every time you do a planned intervention, so a plant that reads MTBR naively can conclude its best-maintained assets are its worst. Always split the count into failures versus planned work; the planned repairs are a cost to optimize, not a reliability failure to alarm on.
Ignoring operating hours. MTBR is a rate, not a raw count. An asset that ran 2,000 hours with 10 repairs is healthier than one that ran 500 hours with 6, even though the second has fewer repairs. Without accurate runtime, ideally from machine counters or connected data, not guesswork, MTBR is just repair tallies wearing a disguise. This is the same runtime data a meter-based PM program needs.
Averaging across a fleet. A plant-wide MTBR across 200 assets is a number nobody can act on. Keep it per asset or per asset class, and pair it with the repair-mode detail that tells you what to fix.
How do you improve MTBR?
Raising MTBR means fewer times a technician has to stop the asset and touch it, from both failures and avoidable minor work. Run this loop per critical asset:
- Log every repair, not just breakdowns. MTBR only works if minor and planned interventions are captured. If operators clear small issues without a record, your MTBR looks better than reality and you lose the signal. Automatic capture beats memory here, the same argument as for any maintenance KPI.
- Separate the two drivers. Split the repair count into failures versus planned/minor work. A short MTBR driven by breakdowns is a reliability problem; one driven by constant small adjustments is a design or setup problem. They need different fixes.
- Attack the top repair modes. Pareto the repairs by cause. A pump that needs a seal top-up every two weeks does not need a better technician, it needs the seal failure cause designed out.
- Match strategy to mode. Wear-driven repeat repairs move onto a condition-based or predictive trigger so you intervene once, deliberately, instead of a dozen times reactively.
- Re-measure on the same definition. MTBR per asset, quarter over quarter, on a fixed rule for what counts as a repair. Rising MTBR with steady or falling maintenance cost is the signature of real progress.
What the numbers say
- MTBR is fundamentally a labor metric, and skilled labor is scarce. The U.S. Bureau of Labor Statistics projects 13% employment growth (2024–2034) for industrial machinery mechanics, machinery maintenance workers, and millwrights, much faster than average, with about 538,300 jobs in 2024 and roughly 54,200 openings a year (BLS Occupational Outlook Handbook). Every repair event MTBR counts is a claim on that scarce time.
- Cutting repair frequency also cuts cost. The U.S. Department of Energy's FEMP O&M guidance, maintained by PNNL, reports that condition-driven maintenance saves 8–12% over preventive-only and the opportunity versus reactive operation can exceed 30–40% (PNNL, O&M Best Practices: Maintenance Approaches). Rising MTBR is one of the clearest ways that saving shows up on the floor.
MTBR and MTBF are not rivals, they are a pair. MTBF tells you whether the asset is reliable; MTBR tells you what it costs your crew to keep it that way; MTTR tells you how long each stop hurts. Read together they steer your reliability effort toward the assets that deserve it, which is the whole point of the equipment reliability program they feed. For how one plant got repair data trustworthy enough to compute metrics like these, see the CLS case study.