Preventive maintenance (PM) is work done before a failure to stop it disrupting production. Crucially, that includes condition-triggered work: if you refit a bearing because it started to rumble or run hot, but before it breaks down, that is preventive β not corrective.
PM comes in flavours: time-based (every N months), usage-based (every N hours/cycles), and condition-based (when a measurement crosses a limit). Predictive is condition-based PM made continuous and forecasting.
The danger is doing too much or too little: over-maintenance wastes money and introduces faults, under-maintenance lets failures through. There is an optimal interval that minimises total cost β and the model below finds it.
1 · What counts as preventive
The cleanest definition is by timing relative to failure: preventive maintenance is done before the failure; corrective is done after. What it is not defined by is how scheduled it was. This trips people up because we associate "preventive" with calendars and "corrective" with surprises β but a condition-triggered, somewhat-urgent intervention is still preventive if it beats the breakdown.
The rule, plainly: if the maintenance is done to prevent a production disruption, it is preventive β even if you only acted because a bearing began to rumble or a temperature climbed. If you refit it before the breakdown, it's preventive. Only the repair done after the failure is corrective. (See the timeline in Corrective Maintenance.)
So preventive maintenance spans everything from a routine quarterly greasing to an unplanned-but-pre-emptive change-out prompted by a vibration alarm. They share the only thing that matters: they happened in time.
2 · The kinds of PM
| Type | Trigger | Good for | Watch out for |
|---|---|---|---|
| Time-based (calendar) | Every N weeks/months | Predictable wear; simple to plan | Wastes life if the clock doesn't match the wear |
| Usage-based | Every N run-hours / cycles / km | Wear that tracks usage, not time | Needs reliable usage counting |
| Condition-based (CBM) | A measurement crosses a limit | Acting only when needed; max life | Needs monitoring & a known P-F interval |
| Predictive (PdM) | A forecast from continuous data | Maximum lead time & planning | Needs sensors, connectivity, analytics |
The trend over the last decades has been to move down this table β from rigid time-based PM toward condition-based and predictive β because acting on actual condition wastes less life and catches more faults. But time-based PM never disappears: for many simple items it is the cheapest, most robust choice, and for failures that are genuinely random it's pointless to monitor at all (an RCM finding).
3 · Too much, too little, or just right
PM has a Goldilocks problem. Do it too rarely and failures slip through β you're effectively running to failure. Do it too often and you waste labour and parts, take production down needlessly, and β counter-intuitively β introduce failures: every intrusive intervention risks infant mortality (a bad reassembly, a contaminated bearing, a nicked seal). This is the "do no harm" principle: unnecessary PM can make things worse.
Between those extremes is an interval that minimises total cost: the PM cost (which falls as you do it less often) plus the expected failure cost (which rises as you do it less often). The sum is a U-curve with a clear bottom. Find it:
Interactive — The optimal PM interval
Live modelCost vs PM interval
4 · Building a PM program that works
- Choose tasks by failure mode, not habit β let FMECA and RCM say which failures a PM task can actually prevent. PM on a random-failure item is wasted.
- Prefer condition-based where you can β it wastes the least life; fall back to time/usage-based where monitoring isn't practical.
- Set intervals deliberately β from the P-F interval for condition tasks, or the cost optimum above for time-based ones; then refine with history.
- Do no harm β minimise intrusive work; every disturbance is a fresh chance to introduce a fault.
- Review and prune β PM programs bloat over time. Periodically cull tasks that catch nothing and add ones that history shows you need.
Where the strategies meet. Preventive is the broad middle ground between reactive corrective and data-driven predictive work. Predictive maintenance is really preventive maintenance done with the best possible information β continuous condition data and a forecast β so you act at the last safe moment, wasting the least life of all.
Key takeaways
- Preventive = before failure, including condition-triggered work done in time.
- Time, usage, or condition-based β move toward condition/predictive to waste less life.
- There's an optimal interval β too much PM wastes money and adds faults; too little lets failures through.
- Choose PM tasks by failure mode (FMECA/RCM), set intervals deliberately, and prune the program.