A maintenance backlog is the queue of identified maintenance work that has been approved but not yet completed, often measured in labour hours or weeks.
A maintenance backlog is the queue of identified maintenance work that has been approved but not yet completed - every fault reported, service due, and repair agreed that is still waiting for someone to do it. It is usually measured in labour hours or weeks of crew capacity rather than a raw count of jobs. A backlog is not a failure in itself; every functioning maintenance operation has one. What matters is whether it is measured, moving, and made of jobs anyone still understands.
How a backlog is measured
Counting jobs misleads, because jobs are not the same size. The standard measure is estimated labour hours of outstanding work divided by available maintenance hours per week, giving a backlog expressed in weeks. A team with 80 hours of queued work and 40 productive maintenance hours a week carries a two-week backlog. Teams without hour estimates can start cruder - job count plus the age of the oldest job - and add estimates as the habit forms. The prerequisite for any of this is that the work is written down somewhere central; a backlog scattered across text messages and memory cannot be measured at all.
What a healthy backlog looks like
Zero backlog sounds virtuous and is not - it means the team is either overstaffed or only finding work reactively. A modest backlog keeps planned work queued so people and parts can be scheduled efficiently; a few weeks of crew capacity is the commonly quoted comfortable range. The signals that a backlog has turned unhealthy are about behaviour, not size: it grows month after month, the oldest jobs are old enough that nobody remembers the fault, safety-related work sits behind cosmetic work, and urgent breakdowns constantly jump the queue - a sign the queue itself is feeding the breakdowns. That last loop is the expensive one, explored further under planned vs unplanned maintenance: postponed small jobs return as failures that erode asset uptime and postpone more small jobs.
Backlog vs deferred maintenance
Backlog is work waiting its turn in the normal flow of scheduling. Deferred maintenance is work consciously postponed - typically for budget - with no committed date. The difference is intent: backlog is “not yet”, deferral is “not now, maybe not ever”. Deferred work deserves its own list, because once it hides inside the ordinary queue it stops being a visible decision and becomes invisible risk.
Working a backlog down
The reliable moves, in rough order:
- Get it all in one place. Every fault report becomes a ticket against the asset, with a description and photo, the day it is found.
- Prune before you sprint. Backlogs accumulate duplicates, fixed-already items, and jobs on retired equipment. Closing those is free progress.
- Age the queue. Sort by oldest first occasionally; stale jobs are either urgent or deletable, never neutral.
- Prioritise by consequence, not by who shouted - safety first, then revenue-affecting, then everything else.
- Protect planned hours. A fixed share of each week goes to queue work, or breakdowns will eat the whole calendar.
Maintenance backlog in practice
For a small team the backlog is simply the open repair queue, and the battle is keeping it written down rather than verbal. In AMPthilly, reported issues become service desk tickets tied to the asset, the queue carries statuses like in progress and awaiting parts, and the ticket history stays on the asset permanently - so the backlog is a list you can sort and prune rather than a feeling that things are slipping.
Related terms
- CMMS - the software category built around managing work orders and backlogs
- Asset Uptime - the availability measure a growing backlog erodes
- Planned vs Unplanned Maintenance - the balance a backlog reveals
- Equipment Servicing - the routine work that makes up much of a healthy queue
- Service Level Agreement - the commitments that set hard deadlines for some backlog items