A preventive maintenance calendar built on a laminated sheet or a spreadsheet has one structural problem: it doesn’t know when a machine actually ran. A task scheduled “every 500 cycles” on a paper calendar gets done on a fixed date instead, because a fixed date is the only thing paper can track, and a machine that ran hard one month and sat idle the next gets serviced on the wrong cadence either way. A PM calendar that reads the same telemetry the rest of the floor already reports doesn’t have that problem, a cycle-based task actually counts cycles.
Two ways a task can be due
A PM task is set on one of two bases, whichever fits the failure mode it’s guarding against. A days-based task, change this filter every 90 days, is due on elapsed time regardless of how much the machine ran. A cycles-based task, service this fixture every 5,000 parts, is due on actual production count, so a machine running two shifts hits it sooner than one running one shift a week, which is the whole point of tracking cycles instead of a calendar date in the first place. A task needs one basis or the other configured. One with neither set has nothing to compute against and reads as unknown instead of defaulting to some assumed interval nobody actually chose.
What “due soon” and “overdue” actually mean
A task isn’t binary, done or not done. It moves through four states as its interval elapses: on track while it has plenty of runway left, due soon once it crosses 80% of its interval, elapsed time or cycles, overdue once it passes 100%, and unknown when there’s no basis configured to judge it against. That 80% line exists so a task shows up on a tech’s radar before it’s actually late, not the moment it crosses the line into a state nobody can plan around anymore. A task creator can also flag any task to raise a repair-style work item automatically the moment it goes overdue, so a task that slips doesn’t just sit in a due list waiting for someone to notice. It shows up in the same queue a real breakdown would.
Compliance needs enough history to mean anything
A compliance percentage, how often a task actually gets done on time, is computed over a trailing 90-day window, and it stays blank below a minimum of three due occurrences in that window instead of showing a number. A task that’s only come due once in 90 days doesn’t have enough occurrences for a percentage to describe a pattern, one on-time completion out of one due date is not a 100% compliance record in any meaningful sense, it’s a single data point wearing a percentage sign. The number stays blank instead of publishing a figure that looks precise and means almost nothing.
MTBF is the interval a task should actually run on
Mean time between failures, computed from an asset’s own actual breakdown history instead of a nameplate spec, is the single best input for setting a PM interval on that specific machine, not the manufacturer’s generic recommendation and not a plant-wide default copied across every asset of the same type. A machine whose failure risk board shows an MTBF around 600 hours and a PM task set to run every 1,000 hours of use is being serviced after it typically would have failed anyway, which defeats the purpose of preventive work. The math only holds once there’s enough real failure history behind it, at least five genuine failure-to-repair cycles, a real breakdown or a stop with a repair actually opened against it, not an ordinary jam. Below that floor the failure risk board says there isn’t enough history yet. It doesn’t estimate from too little evidence, the same abstention discipline that keeps a compliance percentage from publishing off one data point.
That threshold matters for a practical reason: a machine with frequent short jams that never rise to an actual repair doesn’t count those jams toward its failure history at all, so a floor full of minor stops doesn’t read as a machine on the edge of breaking down. Only genuine breakdowns and stops that actually got a repair opened against them count, which is the same distinction that keeps the Maintenance queue itself from burying real repair work under a pile of half-minute uncoded jams.
Reading the failure risk board without over-trusting it
The board isn’t a black-box prediction. It’s an empirical read of how often an asset’s own past failures happened within a given horizon, typically the next seven days, a fraction, not a guess dressed up as certainty. A machine flagged with a rising risk and a dollar exposure figure attached is showing the same expected-cost math that motivates a repair priority call, likelihood of a failure in that window multiplied by how long a typical repair on that asset takes multiplied by what an hour of its downtime actually costs, priced at the asset’s own configured rate where one exists. It’s a case for moving a specific task up the queue, not an automatic verdict, and it says plainly when a machine’s history is too thin to trust a number from at all.
A repeat offender, the same asset showing up in the repair queue again and again, is exactly what a “degrading” flag on the risk board is built to catch: recent intervals between failures running meaningfully shorter than that asset’s own longer-term history, which is a different, more urgent signal than a single failure in isolation.
The calendar and the repair queue are two views of the same discipline
Preventive tasks are cadence-driven, scheduled maintenance whether or not anything’s actually wrong yet. The repair queue is event-driven, a real stop that needs a tech’s attention now. They’re kept as two separate panels on the Maintenance page because they answer different questions, but they feed the same underlying goal, and a task that goes overdue and gets flagged to raise a work item is the calendar handing its own slipped commitment to the same queue a breakdown would land in. Working both together, tightening a cadence on an asset whose MTBF keeps landing before its scheduled service, and treating repeat repair-queue appearances as a signal to check that asset’s interval, is what actually turns a calendar from paperwork into a tool that changes what breaks.
Quick recap
- A PM task runs on elapsed time or actual production cycles, whichever fits the failure mode, not a fixed calendar date regardless of how much the machine ran.
- Due soon starts at 80% of the interval, overdue at 100%. A task with neither basis configured reads as unknown, never a guessed default.
- Compliance percentage needs at least three due occurrences in the trailing 90-day window before it publishes a number at all.
- Set a task’s interval from the asset’s own measured MTBF, not a nameplate spec or a plant-wide default, once there’s enough genuine failure history behind it.
- Only real breakdowns and stops with an actual repair opened against them count toward MTBF and failure risk. Ordinary jams don’t inflate the picture.
- The PM calendar and the repair queue are separate views of one discipline. An overdue task can raise a work item straight into the same queue a breakdown lands in.