What is reactive maintenance?
Reactive maintenance is work carried out in response to a fault or a request, rather than to a schedule. It is measured by response and resolution times against agreed priorities.
Use this diagram
Free to use on your own site, in training material or in a handout, as long as the credit link stays on it. Paste this where you want the diagram to appear.
<figure>
<img src="https://facilityoptix.co.uk/glossary/reactive-maintenance/diagram.svg" alt="reactive maintenance — diagram from FacilityOptix" width="880" height="620" loading="lazy">
<figcaption>
<a href="https://facilityoptix.co.uk/glossary/reactive-maintenance">What is reactive maintenance?</a> — diagram by
<a href="https://facilityoptix.co.uk">FacilityOptix</a>
</figcaption>
</figure>It is unavoidable rather than a failure in itself. Things break; the question a regime answers is what proportion of work is reactive and whether that proportion is falling.
Priority is the mechanism that makes it manageable. A no-heating call in a school in December and a sticking door handle are both reactive, and a system without priorities treats them as the same job.
Its most useful output is data about the planned regime. Repeated reactive calls on the same asset are the clearest possible signal that its PPM schedule is wrong, and almost nobody makes that connection because the two live in different systems.
In practice
A site where reactive spend has quietly overtaken planned.
Nobody decided this. Each individual job was urgent and each was approved on its own merits.
The ratio between planned and reactive is the clearest single indicator of whether a maintenance regime is working, and it moves slowly enough that nobody notices the year it crossed over.
Reactive work is also the most expensive way to buy the same outcome, bought one emergency at a time.
What goes wrong in practice
- Priority assigned by whoever logs the call rather than by defined criteria.
- Jobs closed on attendance rather than on resolution, which makes the numbers look better than the building is.
- Repeat failures on one asset never reviewed against its planned maintenance.
- Requests arriving by email and phone with no single record, so the backlog is unknowable.