Maintenance backlog is the queue of identified but not-yet-completed maintenance work, every open work order and approved request. Measured correctly, it is expressed in crew-weeks: total estimated labor hours in the backlog divided by the crew's available labor hours per week. A count of open work orders tells you almost nothing; crew-weeks tells you how deep the hole is.

Backlog is also the most misread number in maintenance. Zero backlog is not the goal, a crew with no queued work is a crew you cannot schedule efficiently. The goal is a controlled, prioritized, honestly sized backlog. This guide covers the formula, the commonly cited healthy ranges, how to read backlog aging, and a burn-down sequence that starts with a scrub, not overtime.

How do you measure backlog in crew-weeks?

Backlog (weeks) = total estimated labor hours of open work ÷ crew capacity hours per week

Worked example (hypothetical): a plant has 380 open work orders totaling 2,600 estimated labor hours. The maintenance crew is 8 technicians × 40 hours = 320 gross hours a week. But capacity means hours genuinely available for backlog work, subtract PM commitments, meetings, training, and average reactive load. Say that leaves 130 hours a week for scheduled corrective work. Backlog = 2,600 ÷ 130 = 20 crew-weeks. That plant is five months behind, and no amount of urging will schedule its way out without a deliberate burn-down.

Three rules make the number honest. First, every work order needs a labor estimate, unestimated work orders make the backlog unmeasurable, which is a core reason the planner role exists (see planning and scheduling). Second, split the backlog into total backlog (everything open) and ready backlog (planned, parts on hand, executable as soon as scheduled), they answer different questions. Third, compute capacity from real history, not the org chart.

What is a healthy backlog?

The ranges most commonly cited in the reliability community, consistent with the workforce-management metrics published by the Society for Maintenance and Reliability Professionals (SMRP), which defines both Planned Backlog and Ready Backlog metrics in its Best Practices library are roughly:

Treat these as commonly cited rules of thumb, not standards with regulatory force, the right range for your plant depends on asset criticality, outage strategy, staffing model, and seasonality. What the ranges are genuinely useful for is the two failure directions: a backlog persistently above ~6 crew-weeks means work is aging, risk is accumulating, and due dates have stopped meaning anything; a ready backlog below ~1–2 weeks means the scheduler is filling next week with whatever exists rather than what matters, and it often signals work is not being written up at all.

Why does backlog aging matter more than backlog size?

Two plants can both carry 5 crew-weeks of backlog. In one, work flows through in a few weeks. In the other, the same jobs have sat for a year while new urgent work jumps the queue, the backlog has become a graveyard. An aging analysis (how long has each open work order been open?) tells them apart, and it is the first thing to build once the crew-weeks number exists.

Backlog aging funnelWhere is your backlog aging?0–30 days · fresh work entering the queueestimate · plan · stage parts31–90 days · planned, waiting on schedulehealthy if flowing · ready backlog lives here91–365 days · stalled: parts? priority? scope?each job needs a named blocker365+ days · the graveyardscrub it: do it, date it, or delete ita healthy funnel narrows fast, old bands should be nearly empty
The aging funnel. Size alone hides the problem; a large 365+ band means the backlog has stopped being a plan and become a list of regrets.

How do you burn down an oversized backlog? A 6-step plan

  1. Scrub before you schedule. Walk the full list and kill the dead weight: duplicates, work already done but never closed, requests on retired equipment, and wishes nobody would fund. Plants doing a first serious scrub routinely remove a large share of line items without turning a single wrench. Do not skip this, burning down a dirty backlog wastes overtime on ghosts.
  2. Estimate and prioritize what survives. Every surviving work order gets a labor estimate and a priority driven by asset criticality and safety consequence, not by who shouted loudest. Now compute your true crew-weeks number.
  3. Ring-fence burn-down capacity. Dedicate a fixed slice of weekly capacity, say 10–20%, to backlog burn-down, protected in the weekly schedule the same way PM hours are. Without ring-fencing, reactive work eats the slice every week.
  4. Attack the inflow, not just the queue. A backlog grows when inflow exceeds completion. If breakdowns generate most inflow, the burn-down is really a reliability project: check PM compliance and failure patterns on the top offenders. Cutting inflow is the only permanent fix.
  5. Track the trend weekly. One chart: total and ready backlog in crew-weeks, week by week, with the target band drawn on. Falling slope means the plan works; flat means inflow still equals outflow.
  6. Stop at the band, not at zero. When ready backlog reaches the 2–4 week band, reallocate the ring-fenced hours to proactive work. Driving to zero destroys scheduling efficiency and usually means write-ups are being discouraged.
Backlog burn-down (hypothetical example)Burn-down: 20 crew-weeks to the healthy band05101520crew-weekshealthy band ~4–6 wks (commonly cited)scrub: dead WOs deletedmonth 1month 3month 6
A hypothetical six-month burn-down. The steep early drop is the scrub, deleting dead work orders, not extra wrench time. The line stops at the band, not at zero.

What does the data say about backlog and deferred maintenance?

What tooling does backlog management need?

Only three things, but all three: a single system of record for work orders (a CMMS or equivalent, backlog split across a system, a spreadsheet, and a whiteboard cannot be measured), labor estimates on every work order, and a weekly report of crew-weeks plus aging that someone actually reviews. The report is where most plants fail, the data exists but nobody assembles it. Automated reporting against a single source of truth is precisely the gap platforms like Harmony close for plants that ran on paper and spreadsheets; the CLS case study shows the pattern. Once the number is stable and visible, backlog stops being an argument and becomes one of your core maintenance KPIs.