Mean time between removals (MTBR) has been a fixture of MRO parts planning since the earliest reliability-centered maintenance programs. The concept is straightforward: take the total operating hours across a fleet, divide by the number of unscheduled removals for a given component, and you have an average interval between demand events. Set your reorder point at a multiple of that interval, add some safety stock, and you have a plan.
The problem is not that MTBR is wrong. It is that it answers only one question and parts planners are dealing with four or five. When you lean on MTBR as your primary forecast input, you are flying on one instrument while the others are dark.
What MTBR Actually Computes
MTBR is a retrospective average. It tells you what happened in the population of observed removals over a historical window. It says nothing about when the next removal will happen for a specific tail number, or whether the rate is accelerating, or whether the removals in your dataset came from a fleet segment that no longer reflects your current operation.
The average also suppresses variance. If one variant in your fleet removes a particular actuator every 1,200 hours and another removes it every 3,400 hours, the fleet MTBR might be 2,100 hours. That number accurately describes neither variant. You plan to it, you will be short on one and overloaded on the other.
This is not a theoretical concern. Fleet heterogeneity, which we will cover separately in our article on variant mix and age distribution, makes the fleet-average MTBR increasingly unreliable as operators mix aircraft vintages and sub-variants in a single scheduling pool.
MTBR Does Not Capture Utilization Rate Changes
MTBR is expressed in flight hours. The translation to calendar time depends on how many hours the fleet actually flies each month. That utilization rate is not constant.
When a carrier expands summer charter capacity, their utilization jumps. When weather grounds the fleet for three days, it drops. When an aircraft is pulled for a C-check, those months of near-zero flying mean their accumulated hours are lower than the fleet average.
A planner who looks at an MTBR-derived reorder point without adjusting for current utilization is working with a time-offset forecast. If utilization is 20% higher than when the MTBR was calibrated, removals will come faster than the model expects. If utilization dropped sharply in a prior quarter, the historical MTBR may be pulling in removal events from a period of higher flying that inflates the apparent removal frequency.
Removal Cause Distribution is Invisible in MTBR
Not all removals are equal from a parts planning perspective. An unscheduled removal due to in-service failure is a demand signal that matters. A removal for scheduled overhaul at a shop visit is a planned event. A removal because a shop visit was opportunistically expanded to change out components near their life limit is a discretionary removal.
MTBR typically pools all three. If the ratio of unscheduled to scheduled removals shifts, the raw MTBR changes, but not because the underlying failure rate changed. A fleet that starts doing more aggressive shop visit expansions will show a higher apparent removal rate even if nothing is failing at a higher rate in service.
This matters because unscheduled removals drive urgent demand. Scheduled removals can be stocked against a maintenance plan. Discretionary removals are often deferred or advanced based on parts availability. If your demand model cannot distinguish between these, you cannot prioritize stock accordingly.
MTBR Does Not Account for the Cannibalization Loop
Cannibalization is the practice of removing a serviceable part from one aircraft to fix another when stock is unavailable. We cover this topic in more depth in a separate article, but it is worth noting here because it directly corrupts MTBR calculations.
A cannibalized removal is real work: someone physically removed the part, logged it in the maintenance record, and installed it elsewhere. In most MRO systems, that removal gets counted in the demand history. But it was not a demand event in the sense that the part failed or required replacement due to wear. It was a workaround for an inventory shortage.
When those cannibalization events are included in the removal history used to calculate MTBR, the result is an inflated removal rate. The model then recommends higher stock levels to support a demand pattern that was partly self-generated by prior shortages. It is a feedback loop that MTBR math has no way to detect.
What Should Complement MTBR
We are not arguing that MTBR should be abandoned. For stable fleets with consistent utilization and clean historical records, it is a reasonable starting point for long-range planning. The issue is using it as the primary or only input for near-term demand forecasting.
A more complete demand model for unscheduled removals should include: current fleet utilization rate expressed in projected hours for the next 30, 60, and 90 days; removal cause breakdowns that separate unscheduled, scheduled, and discretionary events; tail-number or variant-level removal history that preserves the heterogeneity MTBR averages out; and a flag for cannibalization events that should be excluded from failure-mode demand calculations.
Building these inputs requires cleaner data than many operators have readily available. MRO systems like AMOS or CESIUM do carry most of this information, but it is often in fields that are not consistently populated. Unscheduled vs. scheduled removal codes, removal cause descriptions, and event classifications vary in quality across maintenance records.
At Aerotrax, part of our initial engagement with an operator is an audit of what their removal records actually contain versus what the system fields suggest they should contain. The gap between those two things determines how much of the fuller model we can build immediately versus how much depends on improving upstream data capture over a 60 to 90-day window.
MTBR gets you oriented. It does not get you ahead of the next stockout.
See Aerotrax on your own fleet data
30-day pilot on your removal history. CSV upload, no integration project required.
Request a pilot