Runtime-Based TPM: Trigger Maintenance From Actual Machine Hours

Runtime-based TPM at a glance

Runtime-based maintenance uses validated accumulated operating hours to trigger an approved task. It can complement calendar, cycle-count and condition triggers where runtime is relevant to wear. The maintenance owner must establish the interval from manufacturer guidance, service evidence, operating conditions and required inspections. A state counter supplies a measurement; it does not establish component life or justify extending an interval.

• The same calendar interval can produce different accumulated runtime on assets with different duty cycles. Check whether that matters for the task.
• Runtime hours are a closer proxy for wear on assets whose degradation is driven by running.
• Runtime hours give you a clear, measured trigger. You set the threshold, and the team acts when an asset reaches it.
• It does not apply everywhere. Lubricant ageing, corrosion and seal degradation are time-driven and should stay on the calendar.
• The work order still lives in the CMMS. Guidewheel can supply validated runtime context. Confirm any supported handoff; the CMMS remains the maintenance system of record.

Why calendar intervals drift

For a wear-driven task, compare accumulated use with the basis for the approved interval. Calendar tasks can still be appropriate for ageing, exposure, required inspections or mixed degradation mechanisms.

Take two identical presses on the same monthly preventive schedule. Press A is the workhorse and runs 140 hours a month. Press B covers overflow and runs 30. Over a year, press A accumulates 1,680 running hours and press B accumulates 360. Both receive twelve services.

In this illustrative pair, the services occur every 140 running hours on press A and 30 on press B. That difference is a question for the maintenance owner, not proof that either press is over-serviced or that the components had usable life remaining.

If an approved task limit were 100 running hours, press A would cross it before the monthly date while press B would not. The example illustrates a trigger mismatch. It does not predict when a component will fail or establish that changing the interval is safe.

Compare the actual triggers before changing a plan. A difference in accumulated hours may justify investigation, while inspection findings, load, starts, contamination and required time limits can justify retaining or tightening a calendar task.

Guidewheel's published downtime analysis reports roughly 72 minutes per mechanical-breakdown event in its sample. That event average neither identifies an under-serviced asset nor establishes the time a new maintenance plan would recover. Use the site's actual failure modes, event records and repair history.

Runtime is another proxy for the relevant degradation mechanism; operating conditions and task evidence still matter. The question is which assets that actually helps.

Which assets benefit and which do not

Runtime triggers help where degradation is driven by running. They do nothing, or harm, where it is not.

✅

Good candidates for runtime triggers: bearings and rotating components, belts and drive elements, filters in a running fluid or air path, tooling and contact surfaces, and lubrication intervals on moving assemblies. The test is simple, ask what physically causes the component to reach the end of its life. If the honest answer contains the word "running", runtime is the better trigger. If it contains "sitting", "ageing", "exposure" or "the regulator says so", the calendar is right and should stay.

Good candidates. Bearings and rotating components. Belts and drive elements. Filters in a running fluid or air path. Tooling and contact surfaces. Lubrication intervals on moving assemblies. Anything whose wear mechanism is friction, load cycling or throughput.

Poor candidates, where the calendar is correct. Lubricant and fluid degradation, which is largely a function of elapsed time, oxidation and contamination rather than hours run. Seals and elastomers, which harden and crack on the shelf as readily as in service. Corrosion and environmental exposure, which continue whether or not the machine runs. Statutory and insurance inspections, which are legal obligations on a date regardless of any engineering argument. Battery and backup systems.

Mixed cases needing judgement. A hydraulic system has both: the pump wears with running hours, and the oil degrades with time. These need two triggers, not one, and forcing a single basis onto them is how plants end up with clean oil in a worn pump or a good pump full of degraded fluid.

The test to apply. For each asset, ask what physically causes the component to reach the end of its life. If the honest answer contains the word "running", runtime is the better trigger. If it contains "sitting", "ageing", "exposure" or "the regulator says so", the calendar is right and should stay.

Document the basis of each task separately. The useful output is a list of justified time, runtime, cycle or condition triggers, including tasks that still need evidence; do not assume a standard percentage belongs on each basis.

For the assets where neither trigger fits and failure is expensive, condition-based monitoring is the answer rather than either interval. Guidewheel's guidance on predictive maintenance without PLCs covers when to go beyond current sensing for critical rotating equipment.

With the asset list split, the thresholds have to come from somewhere.

Calculating the threshold

Convert the interval you already trust rather than inventing a new one.

The method, in five steps

1. Measure the actual duty cycle of a representative asset currently on the calendar interval. Not the assumed duty cycle, the measured one. This is the step that requires runtime data and the reason the exercise was not practical before.
2. Compute the running hours the current interval delivers. Monthly interval, 95 measured running hours per month, gives 95 hours as the implicit threshold your existing schedule already uses.
3. Have the responsible maintenance owner check current manufacturer guidance, inspection findings, duty, load, failure history and mandatory time limits. An implicit runtime value from a calendar plan is not itself an approved interval.
4. Approve the runtime threshold and any margin through the maintenance process. Record the evidence and review triggers. Thin evidence calls for further assessment or retaining the existing approved task, rather than choosing an arbitrary numerical margin.
5. Set a maximum elapsed time alongside it. A runtime trigger on a rarely used asset can go years without firing, and time-driven degradation continues regardless. Every runtime trigger should carry a calendar backstop, set by the responsible maintenance owner from applicable guidance and evidence. Do not double an existing interval by default.

A worked trigger calculation: suppose the maintenance owner has independently approved a 100-running-hour task limit and a maximum elapsed-time limit for both presses. At 140 running hours per month, press A reaches the running-hour trigger in about 0.71 month. At 30 hours per month, press B reaches it in about 3.33 months. The earlier approved time or runtime trigger governs. These calculations illustrate timing, not a recommended service interval or proof that fewer services are appropriate.

Do not skip the backstop. It is the difference between a runtime programme and a slowly deteriorating asset that never triggered.

Once the threshold fires, something has to happen with it.

Wiring it into the maintenance workflow

The monitoring system counts hours. The CMMS does everything else.

The handoff, in four steps

1. Accumulated runtime crosses the threshold on a monitored asset.
2. A notification goes to the maintenance planner, carrying the asset, the hours accumulated, and the date the threshold was crossed.
3. The planner raises a work order in the CMMS, which remains the system of record for the work, the parts, the labour and the history.
4. On completion, the runtime counter for that asset resets.

Guidewheel can supply validated runtime information to a maintenance workflow. Scope the threshold notification and any CMMS handoff. Keep work orders, parts, labor and maintenance history in the agreed system of record. The boundary between the two systems is covered in machine monitoring versus CMMS, and it matters here because a runtime programme that tries to live outside the CMMS creates a second, competing maintenance schedule, which is worse than the calendar it replaced.

Exception review is the part that gets skipped. Once a month, look at the assets whose triggers fired unusually early or unusually late relative to expectation. Early firing means utilisation went up and the plant should know why. Late firing means an asset is being used less than assumed, which may be a capacity question rather than a maintenance one. Both are useful signals that the calendar never produced.

Keep the reset honest. If a service is deferred, the counter keeps counting. A programme where deferrals silently reset the clock is a programme that has stopped measuring anything.

Start small. Three assets, one quarter, running in parallel with the existing calendar schedule rather than replacing it. Compare what each would have triggered. Record the observation, planning and validation effort. The comparison informs an assessment; it does not by itself prove a financial return.

Then measure whether any of it helped.

Measuring whether it worked

Measure production recovery, not schedule compliance.

Compliance measures whether the maintenance team did what the system told them, which is worth knowing and is not the point. The question is whether the plant lost fewer hours. Three measures answer it:

Unplanned stops on the affected assets: compare both count and total measured minutes before and after, accounting for runtime, load, product and observation period. Do not multiply event-count reduction by a reported cross-plant average and call the result recovered hours.

Services performed: compare actual task count, labor, parts, inspection findings and failures with the approved previous basis. Fewer services is not success if risk or failures increase.

Availability: compare the measured result on the affected assets with the baseline and the relevant maintenance mechanism. Investigate adverse findings promptly; a lack of change alone does not identify a bad threshold.

Choose an observation period long enough for the task frequency and failure evidence, with interim safety and reliability reviews. Do not wait for a calendar milestone to address an adverse result.

Watch for the two failure modes. Runtime data that is not trustworthy produces triggers that are worse than the calendar, which is why state accuracy should be validated first using the method in validating run, idle and down accuracy. And a programme with no backstop lets rarely-used assets drift, which shows up as failures on exactly the equipment everyone stopped thinking about.

One thing to keep clear. A runtime trigger says an asset has accumulated the hours at which you decided to act. Set that expectation with your team up front, so everyone knows what the trigger means and what the next step is. Start with the calendar-versus-runtime comparison on a few assets, and build from there.

For the baseline against which recovery is judged, see ideal versus actual cycle time, and for the underlying state and runtime capture, automated downtime reason tracking . The honest limits of the product are in when Guidewheel is not the right tool.

Sensors connect to machine power cables to establish runtime context without an initial PLC connection. Talk to the Guidewheel team about representative assets, state validation and the maintenance workflow you want to test.

Frequently asked questions

What is runtime-based maintenance?

Triggering a maintenance task when an asset accumulates a defined number of running hours, rather than when a date arrives. It replaces the calendar's implicit assumption that every asset accumulates wear at the same rate, which is false on any floor where one machine runs a hundred hours a month and another runs thirty.

How is runtime-based TPM different from condition-based maintenance?

A runtime trigger fires when an asset reaches the running hours you chose to act on. Condition-based maintenance watches the asset's own signals, such as vibration or temperature, and acts on what they show. Runtime triggers are the simpler first step: you can start with measured hours on assets you already run, then add condition signals where failure is expensive.

Which assets should use runtime triggers instead of calendar intervals?

Assets whose degradation is driven by running: bearings, belts, drive components, filters in a running path, tooling and contact surfaces. Keep the calendar where degradation is time-driven, which covers lubricant and fluid ageing, seals and elastomers, corrosion, and any statutory inspection. Hydraulic systems typically need both triggers rather than a choice between them.

How do you convert a calendar interval into a runtime threshold?

Measure actual duty and calculate the runtime implied by the existing plan. Have the maintenance owner approve any change against manufacturer guidance, inspection findings, operating conditions and mandatory time limits. Record the approved runtime threshold, margin and maximum elapsed time. The backstop is not optional: without it, a rarely used asset can go years without triggering while time-driven degradation continues.

Does Guidewheel create the work order?

Keep the work order in your CMMS. Agree how a runtime threshold reaches the planner, who raises the order and how its completion is recorded. Validate the notification or integration before relying on it. A runtime programme that tries to live outside the CMMS creates a second competing schedule, which is worse than the calendar it replaced.

About the author

Lauren Dunford is the CEO and Co-Founder of Guidewheel, a FactoryOps platform that empowers factories to reach a sustainable peak of performance. A graduate of Stanford, she is a JOURNEY Fellow and World Economic Forum Tech Pioneer. Watch her TED Talk, the future isn't just coded, it's built .