Maintenance backlog is the sum of all maintenance work already identified and not yet completed, measured in labor-hours (HH). Divided by the team's execution capacity, it becomes a measure of time: how many weeks it would take to clear the queue if no new work came in. That is why the backlog is the most direct ruler for answering two questions every maintenance manager hears: "is the team keeping up?" and "do we need to hire?".
In this article, you will find the backlog formula explained in words, a complete numerical example, the range considered healthy in weeks (with the reasoning and the sources), and the measurement errors that make the indicator lie.
What is maintenance backlog
The backlog is the maintenance service queue: everything already identified as necessary and not yet closed. In practice, work orders enter the queue in four situations:
- Planned: orders that have already gone through planning (scope, materials, estimated HH) and are waiting to be scheduled.
- Pending: open orders still waiting for planning or some resource (a part, a release, a third party).
- Scheduled: orders with a date and team defined, waiting for execution.
- Executed and not closed: orders already carried out in the field, but that have not yet had their technical closure in the system. They remain in the queue because, as far as the system is concerned, the work still exists.
One important detail: backlog is not a synonym for delay. Every healthy maintenance operation has a queue, because it is the queue that feeds the scheduling of the coming weeks. The problem is not having a backlog, it is having too much, too little, or a backlog growing out of control.
The backlog formula
Backlog (in weeks) = Sum of the HH of the orders in the queue ÷ Team's available HH per week
In words: add up the estimated work hours of all planned, pending, scheduled, and executed-not-closed orders. Then divide by the amount of labor-hours the team can effectively deliver per week. The result is the time, in weeks, the team would take to clear the queue.
The denominator hides the catch in the formula. Available HH is not the total contracted hours, but rather:
Available HH = Team's total HH × productivity factor
No maintenance worker devotes 100% of the shift to work orders: there are commutes, meetings, training, waiting for releases. Using full HH in the denominator is the most common error in the calculation, and it makes the backlog look smaller than it is. We show how to estimate that factor with real data in the article on real maintenance capacity for scheduling orders.
Step-by-step numerical example
The numbers below are hypothetical, built to make the mechanics of the calculation clear.
Step 1: calculate the available HH per week.
- Team: 10 technicians on a 40-hour work week, that is, 400 HH per week on paper.
- Estimated productivity factor: 70%.
- Available HH = 400 × 0.70 = 280 HH per week.
Step 2: add up the HH of the queue.
- Planned orders: 320 HH.
- Pending orders: 260 HH.
- Scheduled orders: 180 HH.
- Executed and not closed orders: 80 HH.
- Total in the queue: 840 HH.
Step 3: apply the formula.
Backlog = 840 HH ÷ 280 HH per week = 3 weeks. If nothing new came in, this team would take 3 weeks to clear the current queue.
What is the healthy backlog range (and why)
The public references in the Brazilian market converge on a range between 2 and 4 weeks, with nuances among the sources. Engeteles, a maintenance engineering consultancy, points out that a healthy backlog should range between 3 and 4 weeks of work. Fracttal, a maintenance software vendor, classifies 1 to 2 weeks as a good balance between demand and capacity, 3 to 4 weeks as a zone of attention, and above 4 weeks as a risk of delays and overload.
PM Run's practical recommendation is to work with the range of 2 to 4 weeks as a reference, and the justification comes from the two extremes:
- Below 2 weeks: the queue is too short to feed efficient scheduling. The scheduler has no work front to build the following week, the team alternates between idleness and urgency, and any demand spike disorganizes the routine. A very low backlog may also indicate an oversized team or, worse, work that is not being recorded.
- Above 4 weeks: the queue grows faster than the execution capacity. Preventive work starts being postponed to handle emergencies, prioritization comes to be done by whoever shouts loudest rather than by risk, and the aging of the queue increases the chance of failures in critical assets.
Two caveats complete the reading. First: the ideal range varies with the sector, the criticality of the assets, and the maintenance strategy, so treat 2 to 4 weeks as a starting point, not as law. Second: the trend matters more than the absolute number. A stable backlog of 3 weeks is a sign of balance; a backlog that goes from 2 to 4 in three months is an alarm, even while it stays "within the range".
Backlog in weeks, in days, or in HH: which to use
The same queue can be expressed in three ways, and each one serves a different conversation:
- In HH: it is the raw number (840 HH, in the example). Useful for the planner to build the schedule, but it says little to an outsider: is 840 HH a lot or a little? It depends on the team.
- In days or weeks: it is the HH of the queue divided by the capacity of the period. It is the most useful form for management, because it embeds capacity and allows comparing teams of different sizes. A queue of 3 weeks means the same thing in any plant.
- As a dimensionless ratio: some texts present the backlog as a ratio in which 1 would be the ideal balance between demand and capacity of the period. That reading is valid for a snapshot of the day, but it hides the question that matters (how many weeks of queue exist?), which is why the version in weeks became the market standard.
Whatever unit you choose, keep just one: switching between them from one month to the next prevents reading the trend, which is where the indicator delivers value.
How to track it: the trend curve
The backlog of a single month is a snapshot; management happens in the film. Plot the indicator week by week and read the shape of the curve:
- Stable curve within the range: demand and capacity in balance. This is the target scenario.
- Constantly rising curve: demand structurally exceeds capacity. The typical causes: real degradation of the assets (insufficient preventive work), falling productivity, or poorly filtered demand entering the queue.
- Sawtooth curve: it rises and drops in cycles. It usually reveals mass closing efforts (accumulated reporting being cleared all at once), instability in scheduling, or difficulty in releasing equipment from operations.
If, with a clean queue, reporting up to date, and productivity addressed, the backlog remains structurally above the range, then the sizing conversation holds up: the surplus HH of the queue divided by the useful HH of one technician per week indicates how many people are missing, with numbers on the table instead of perception.
When the backlog lies
The backlog is one of the easiest indicators to distort, because it depends on estimates and on recording discipline at both ends of the fraction:
- Late reporting: executed orders that go days without closure keep adding to the queue. The backlog looks bigger than it is, and the classic reaction (asking for more people) attacks the wrong problem. This effect is detailed in the article on how late reporting distorts maintenance KPIs.
- An unpruned queue: duplicate orders, services that have lost their purpose, and operations "wishes" that were never triaged inflate the numerator. The planner needs to act as a filter for requests before they become an order.
- HH estimated by guesswork: if the orders have no consistent HH estimate, the sum of the queue is fiction. A standard estimate per type of service is worth more than a blank field.
- Overestimated capacity: using contracted HH without a productivity factor in the denominator makes the backlog look comfortable while the team is drowning.
How to reduce the backlog without hiring
When the backlog goes beyond the healthy range, hiring is the most expensive lever and almost never the first. Before it:
- Prune the queue: cancel duplicates, reassess old orders, and close what has already been executed. It is common for an honest cleanup to reduce the backlog by weeks without executing a single order.
- Prioritize by criticality: with the queue above capacity, the question is not "how to do everything", it is "what cannot wait". A criticality and risk matrix instead of first come, first served.
- Attack productivity, not the shift: reducing waits for parts, releases, and information increases the available HH without increasing headcount. Here the backlog talks directly to MTTR: the same waste that inflates repair time consumes the team's capacity.
- Stratify by specialty: the aggregate backlog hides bottlenecks. Calculate it by specialty (mechanical, electrical, boilermaking): it is common to discover that the "staffing shortage" is a shortage of a single specialty.
The backlog is one of the central indicators on the PCM dashboard, alongside MTTR, MTBF, and availability. To see how it fits into the set, consult the guide to the 12 maintenance indicators and the complete guide to maintenance planning and control (PCM).
Frequently Asked Questions
What is maintenance backlog?
It is the maintenance service queue: the sum, in labor-hours, of all orders already identified and not yet closed, including planned, pending, scheduled, and executed without closure. Divided by the team's weekly capacity, it becomes a measure in weeks of accumulated work.
How do you calculate maintenance backlog?
Add up the estimated HH of all orders in the queue and divide by the team's available HH per week, which is the total HH multiplied by the productivity factor. A queue of 840 HH with a capacity of 280 HH per week results in a backlog of 3 weeks.
What is the ideal maintenance backlog?
Market references converge on a range between 2 and 4 weeks: below that there is not enough work front to schedule and there may be idleness; above it, the queue grows, preventive work is delayed, and prioritization becomes reactive. The indicator's trend matters more than the value of a single month.
Does a high backlog mean the team is understaffed?
Not always. Before hiring, check whether the queue is clean (no duplicate or obsolete orders), whether reporting is up to date, and whether productivity is not being consumed by waits. Often a high backlog is a symptom of poorly filtered demand or poorly used capacity, not of insufficient headcount.
See your team's real backlog
The calculation in this article depends on an up-to-date queue and reporting kept current, and that is exactly what a digital process ensures. PM Run Planning shows the workload by specialty and by worker in real time, integrated with SAP PM, so that the backlog you see is the backlog that exists in the field. Get to know PM Run Planning and see your team's real backlog.
