PM Scheduling Methods: Calendar-Based, Usage-Based, and Condition-Based Triggers

Three Ways to Trigger a PM, and Why They're Not Interchangeable

It's the Tuesday before a holiday shutdown. The conveyor belt on the packaging line is running an extra shift to clear backlog, and nobody told the PM schedule. The belt's last greasing was 83 days ago, on a 90-day calendar interval set back when the line ran one shift a day. At three shifts, that belt has done the work of nearly 250 calendar days in 83. The bearing seizes at 2 a.m.

Meanwhile, across the floor, a forklift that's been parked for six weeks waiting on a part still got its monthly inspection anyway, because the calendar said it was due — another hour of a technician's time spent inspecting a truck that hasn't turned a wheel in a month.

Same facility, same calendar, two opposite failures: one asset under-maintained because the clock doesn't track wear, the other over-maintained because the clock doesn't track idle time. Both are scheduling problems, not task problems — the work orders were written correctly, the trigger was wrong.

Most spreadsheet-run PM programs start with one scheduling method, usually calendar-based, because it's the easiest to set up with nothing but a date column. It's also the wrong default for a meaningful share of the assets on a typical floor. By the end of this, you'll be able to look at any piece of equipment and decide — on purpose, not by default — whether it should run on a calendar, a meter, or a condition check.

Calendar-Based Scheduling: The Default, and Its Blind Spot

Calendar-based scheduling triggers a PM on a fixed time interval — every 30 days, every quarter, every 6 months — regardless of how much the asset actually worked during that window. It's the easiest method to build in a spreadsheet: one date column, one interval, one formula for "next due date."

It fits assets whose condition degrades mostly with the passage of time rather than with use. A fire extinguisher doesn't wear out from being used (it's rarely used at all); its seal and pressure degrade on a clock regardless of activity, so an annual calendar check is the right trigger. The same logic applies to building-system PMs — HVAC filter changes on a seasonal calendar, roof inspections before and after winter, calibration-adjacent checks tied to a regulatory period rather than to run hours.

Calendar scheduling breaks down exactly where the conveyor example above breaks down: any asset whose workload swings with production volume, shift count, or season. A calendar interval set for average usage will under-maintain the asset during a surge and over-maintain it during a lull. If you're setting up a full schedule for the first time, how to build a preventive maintenance schedule walks through the baseline structure most programs start from before they start splitting assets out by trigger type.

Usage-Based Triggers: Scheduling by Meter, Not the Clock

Usage-based scheduling triggers a PM on a count of actual work done — run hours, cycles, units produced, miles, or gallons pumped — rather than days elapsed. A forklift PM'd every 250 operating hours instead of every 30 days gets serviced proportionally to how hard it's actually being driven. A stamping press PM'd every 100,000 cycles ties the service interval to wear, not to the calendar page.

This is the correct trigger for any asset where usage intensity varies meaningfully across the fleet or across the year — mobile equipment, production machinery that runs at different rates by product mix, pumps and compressors whose duty cycle depends on demand. The tradeoff is the one implied in the name: usage-based scheduling only works if someone is actually recording the meter. A run-hour PM on a forklift with no hour meter, or one where the meter reading isn't logged at each shift, degrades back into a calendar guess with extra steps.

That recording step is also where usage-based programs most often fail in practice — not because the logic is wrong, but because the meter reading lives in someone's head or a sticky note instead of a tracked field. A dedicated log for meter readings and usage thresholds — which is what the meter/usage-based PM trigger tracker is built around — solves the mechanical half of the problem: one row per asset, a running meter reading, a threshold, and a flag the moment an asset crosses it. It doesn't solve the discipline half; someone still has to walk the floor and read the meter. But it does stop "due every 250 hours" from quietly becoming "due whenever someone remembers."

Condition-Based Scheduling: Letting the Equipment Tell You

Condition-based scheduling doesn't run on a date or a count at all — it triggers on a direct measurement of the asset's actual state. Oil analysis flags contamination before a bearing fails. A vibration reading outside its normal band flags an imbalance before it becomes a seized shaft. An amp-draw reading above baseline on a motor flags a developing mechanical fault before the motor trips.

Condition-based maintenance replaces the question "has enough time or use passed?" with the question "what is the equipment's condition telling us right now?"

This is the most precise of the three methods and also the most demanding. It requires a baseline reading to compare against, a sensor or inspection routine capable of taking that reading repeatably, and someone trained to interpret what a deviation means. That's realistic for a subset of critical rotating equipment — motors, gearboxes, compressors — and much less realistic to apply across an entire asset register of three hundred items in a spreadsheet-run program. Bearing wear is a useful case for why condition monitoring earns its keep on the assets where it's used: bearing failures account for an estimated 50%–65% of all electric motor failures, and poor lubrication practice is behind most of that share (Machinery Lubrication/Noria, 2018) — which is exactly the kind of slow-developing fault a vibration or oil reading catches well before a calendar or meter trigger would.

Condition-based triggers don't have to mean expensive sensor hardware. A manual vibration pen, a simple oil-sample kit, or even a scheduled visual/audible inspection routine (listening for bearing noise, checking for oil sheen, feeling for abnormal heat) is condition-based monitoring — it's just a lower-resolution version of the same idea. The distinction that matters for scheduling purposes isn't the instrument, it's that the trigger is a measured state, not a date or a count.

Choosing a PM Scheduling Method for Each Asset

Picking among the three pm scheduling methods isn't a one-time decision for the whole plant — it's a decision made per asset, and it starts with the same two questions every time:

How does this asset degrade — with time, with use, or with a specific measurable wear mechanism? A seal that dries out with age wants a calendar. A bearing that wears with cycles wants a meter. A gearbox whose failure mode is a slow-developing vibration signature wants a condition check.

What does it cost if this asset fails between scheduled checks? This is where criticality enters the decision. A low-criticality asset with mild consequences from failure doesn't justify the overhead of condition monitoring — calendar or usage scheduling is proportionate. A high-criticality asset where failure stops the line is exactly where the extra setup cost of a condition-based trigger earns its place. If criticality ranking isn't already driving your interval decisions, asset criticality ranking covers the consequence-times-likelihood scoring method that should sit upstream of any scheduling decision — scheduling method is a consequence of criticality, not a replacement for it.

In practice, most plants land on a mix: calendar for building systems and low-criticality fixed equipment, usage for mobile and variable-duty-cycle machinery, condition-based for the small number of high-criticality rotating assets where a failure is expensive enough to justify the extra setup. If you're populating interval data for the first time, a PM interval reference library of manufacturer-typical starting points by equipment type — and a bulk interval assignment pass to apply them across a full asset register — will get the baseline numbers in place faster than researching each asset one at a time. Treat every number in a reference library as a starting point to verify against your own manufacturer documentation, not a universal setting.

Blending Methods on the Same Asset

These three methods aren't mutually exclusive on a single piece of equipment. A compressor might carry a calendar-based filter change (time-degrading part), a usage-based oil change (cycle-degrading fluid), and a condition-based vibration check (bearing wear) — three PM lines, three trigger types, one asset. That's normal, not over-engineering. A compressed air system left to run down is a good illustration of what's at stake in getting the trigger right: leaks in a poorly maintained system can waste 20%–30% of a compressor's output, while a well-maintained system holds leakage below 10% (U.S. DOE, 2004) — the difference between those two numbers is mostly a scheduling discipline problem, not an equipment problem.

The practical risk of blending methods is tracking complexity: three trigger types per asset means three different "is this due" calculations instead of one. A spreadsheet handles this fine as long as each PM line carries its own trigger type, its own last-done value, and its own interval — which is the structure a PM task and interval worksheet is built to hold, with one row per task rather than one row per asset.

Setting Up Triggers You Can Actually Track

None of the three pm scheduling methods works if the underlying data isn't captured consistently. Calendar triggers need a reliably logged completion date. Usage triggers need a meter reading recorded on a cadence tight enough to catch a threshold crossing before it's missed by a wide margin. Condition triggers need a baseline reading and a defined deviation threshold, written down somewhere besides a technician's memory.

Before adding a second or third trigger type to your program, confirm you can actually sustain the data capture it requires — a condition-based PM with no one reliably taking the reading isn't more precise than a calendar PM, it's just a calendar PM with extra paperwork. Start with the asset or two where the failure consequence is highest, prove the tracking discipline works there, then expand. A broader walkthrough of building the schedule end to end, including how PM compliance is tracked against whichever trigger type you choose, is covered in the preventive maintenance planning guide.