Turbines and generators need run-hour-based PM because their main failure modes track operating hours, not calendar days. A turbine that runs baseload all year wears out its hot gas path much faster than one that mostly sits idle as backup power. Both units are the same age on the calendar. Only one of them has actually earned a teardown. Run-hour-based PM ties inspections and part swaps to real meter readings instead of a fixed date, so maintenance happens when the equipment is actually due for it. That's the difference between fixing a problem before it happens and finding out about it during an outage.
Key Takeaways
Run-hour-based PM is preventive maintenance triggered by a measured usage value, such as fired hours or starts, instead of a fixed calendar date. A work order opens automatically once an asset's meter crosses a threshold set by the manufacturer. No one has to pick that date a year in advance.
The National Institute of Standards and Technology describes this pattern directly. Preventive maintenance runs a set routine "at prescribed intervals (e.g., number of hours)," not just by the passage of time, according to NIST's summary report on advanced monitoring technologies. That distinction is the whole point. A meter shows how hard a machine actually worked. A calendar date does not.
Most Computerized Maintenance Management System platforms, including Cryotos, support this as a dynamic PM rule that runs alongside static, calendar-based PM. The rule watches a connected meter and opens the work order the moment the threshold is hit, with no one needing to remember to check it.
Turbines and generators degrade through mechanisms that scale with operating stress over time, not with the number of days since installation. A turbine's hot gas path, a generator's winding insulation, and the bearings in both wear out from running, not from sitting still.
Wikipedia's overview of gas turbine engineering notes that blade life is limited by creep and thermal fatigue that build up from high operating temperature over time. Peaking plants may run "a few hours per day to a few dozen hours per year," while baseload units run nearly nonstop. Two turbines of the same model, installed the same month, can sit at completely different points on their wear curve within a single year.
The Four-Signal Wear Model is a simple way to think about what actually drives this wear in turbines and generators:
None of these four signals shows up on a calendar. Most maintenance teams that switch to hour-based tracking find their highest-risk units aren't the oldest ones on the calendar. They're the ones with the roughest mix of these four signals.
Skipping run-hour-based PM causes two opposite problems: wasted spend on assets that barely ran, and missed wear on assets that ran harder than expected. Both come from the same root cause. A calendar can't tell the difference between a standby generator and a baseload turbine.
The cost of getting this wrong is well documented. The U.S. Department of Energy notes that cycling a gas turbine on and off can triple its maintenance costs compared with running it in longer, steadier intervals. That is exactly the kind of pattern a calendar-only program has no way to see coming. That extra cost shows up long before any single part actually fails. Most operations that successfully avoid this treat the meter, not the date, as the trigger for every major inspection.
Warranty and long-term service agreements raise the stakes further. Reliability programs built around ISO 55000 asset management principles generally expect maintenance intervals tied to actual usage. A failure traced to a missed hour-based service action is a common reason insurers and OEMs deny a warranty claim.
See how much unplanned downtime is actually costing your operation with the MTBF calculator.
Equivalent Operating Hours (EOH) is a composite figure that adds weighted penalties for starts and trips on top of raw run-hours. A thermal cycle stresses components more than an equivalent hour of steady running does. Raw run-hours alone can understate wear on a unit that often starts and stops, even if its total hours look modest.
| Factor | Raw Run-Hours | Equivalent Operating Hours |
|---|---|---|
| What it counts | Time the asset ran under load | Run-hours plus weighted penalties for starts and trips |
| Best suited to | Steady baseload units with few starts | Peaking or cycling units with frequent starts and stops |
| Risk if used alone | Understates wear on cycling units | Needs OEM-specific penalty factors to calculate |
| Typical source | A single hour meter or historian tag | OEM formula combining hours, starts, and trip counts |
Most gas turbine OEMs schedule combustion inspections, hot gas path overhauls, and major inspections against EOH rather than raw hours, for exactly this reason. A maintenance system that tracks only one meter per asset can't reproduce this calculation. It needs run-hours and event counts as separate, addable inputs.
A working run-hour PM program needs continuous meter data, threshold-based triggers, and a full service history for every tracked asset. Without all three, "run-hour-based" ends up being a spreadsheet someone updates when they remember to.
A maintenance management system needs to hit all six. Miss even one, and the program quietly drifts back into calendar habits within a year. Most teams that skip one of these six find out the hard way, usually during an outage that a calendar never saw coming.
Cryotos handles run-hour-based PM through its dynamic preventive maintenance engine, fed by live meter data and backed by checklists, history, and reporting. Each item on the requirement list above maps to a specific part of the platform, not to one generic "PM module."
Cryotos documents this same pattern as meter-based maintenance. The meter decides when work happens. The software makes sure nothing depends on someone remembering to check it. Most maintenance teams that make this switch keep their existing OEM manuals and inspection scopes; only the trigger changes, from a date to a threshold.
A run-hour PM program is proven by falling breakdown rates, not by the fact that it runs on meters instead of dates. Three numbers tell most maintenance teams whether their current thresholds are set correctly.
A declining MTBF or rising breakdown hours on one specific asset, even after the switch to run-hour PM, usually means that asset's threshold was set too loosely for its real duty cycle. That's the signal to go back and tighten it.
Calendar-based PM assumes every asset runs the same amount between services, but a baseload turbine and a standby generator build up wear at very different rates. A fixed date either wastes maintenance spend on the low-use asset or arrives too late for the high-use one.
Run-hours count only the time an asset spent operating. Equivalent Operating Hours add weighted penalties for starts and trips on top of run-hours, because those events stress components more than an equivalent hour of steady running.
It reads a connected meter, either through a direct link to the plant's control system or through logged manual readings, and compares the current value against a threshold set for that asset and inspection type.
No, the two work together. Run-hour-based PM tells a team when a scheduled inspection is due, while condition monitoring can catch problems developing between those scheduled points.
Most teams need a few weeks to pull historical hours and starts data, set up meter feeds and thresholds in the CMMS, and check the new triggers against at least one full inspection cycle before retiring the old calendar schedule for good.
Yes. Standby and backup generators can track engine hours from a simple hour meter or the genset controller instead of fired hours, and the same threshold logic still applies. Exercise runs, oil changes, and load-bank tests trigger off accumulated hours rather than a fixed monthly date, so a rarely used unit isn't serviced on the same schedule as one that runs constantly.
Turbines and generators will keep wearing out on their own schedule, no matter what the calendar says. Schedule a free demo to see how Cryotos turns your fleet's actual run-hours into maintenance that happens exactly when it's due.
Cryotos AI predicts failures, automates work orders, and simplifies maintenance—before problems slow you down.
