Most PdM software is designed around an assumption: the reliability engineer sits at a desk, processes alerts, dispatches work orders, and tracks outcomes in a tidy feedback loop. We've had enough conversations with working reliability engineers to know that assumption is wrong in almost every detail.
Over the past year, we spoke with six reliability engineers at heavy-industry facilities — three in refining and petrochemical, one in aggregate and mining, and two in food and beverage manufacturing. Their job titles were similar. Their actual days were not.
The morning is not a queue-clearing exercise
Every RE we spoke with described a morning that began not at a dashboard but somewhere physical — a walk, a drive, a quick look at equipment that had been flagged overnight by a colleague, a millwright, or their own instinct. "I don't start my day looking at software," said one RE at a Gulf Coast refinery. "I start it talking to the night-shift operator who ran the equipment."
The vibration monitoring system, in most cases, was consulted third or fourth — after the operator conversation and after a quick inspection of whatever had physically triggered concern. This isn't a criticism of monitoring tools; it reflects something real about how industrial knowledge travels. Operators notice things that sensors either don't capture or don't surface clearly: an unusual smell, a sound character change that doesn't yet register as an amplitude threshold crossing, a slight increase in bearing housing temperature that they spotted by touch before any IR scan was scheduled.
The implication for PdM tools: presenting an alert queue as the entry point to the workday is a category error. The RE arrives with pre-existing context that the tool doesn't know about. The tool's job is to enrich that context, not replace it.
The route versus the watch: two fundamentally different workflows
A persistent assumption in PdM product design is that continuous monitoring simply replaces a monthly route — same information, higher frequency. In practice, continuous monitoring creates a qualitatively different workflow with different cognitive demands.
On a monthly vibration route, the RE is the data collector. They put the accelerometer on the bearing housing, log the reading, move to the next machine. Judgment happens later, offline, when they review trends. The route itself is mechanical.
With continuous monitoring, the RE is no longer the data collector. What they become is harder to describe cleanly: part interpreter, part exception handler, part historian. The question shifts from "what is the vibration level at point 14B?" to "why did point 14B show a 3 dB AE spike at 2:17 AM on Thursday when nothing else changed?"
That's a more interesting question, but it's also more demanding. Two of the six REs we spoke with explicitly said they had to develop new mental models for their work when continuous data arrived. "I was used to snapshot thinking," one told us. "Now I have to think in trajectories."
Where the workload actually goes
A common objection to continuous monitoring from RE teams is: "we don't have time to watch a 24/7 stream." That objection is grounded in a false premise — nobody is watching a 24/7 stream. The value of continuous monitoring is that it compresses the human attention requirement to a small number of meaningful exceptions per day rather than spreading a route workload across a monthly calendar.
The honest accounting of where time goes under continuous monitoring, based on our conversations:
- Alert triage (15–30 min/day when alert rates are controlled): The RE reviews flagged items, decides which warrant physical follow-up, assigns or dismisses. This replaces nothing — route-based programs had inspection time too, it just arrived in monthly batches.
- Cause investigation (variable, 0–2 hr/day): When a sensor trend is anomalous, someone has to go figure out why. This is where the good REs spend disproportionate time, and where continuous data actually makes the investigation faster because you have the temporal signature of the event.
- Planning and communication (unchanged): Work order creation, parts coordination, scheduling with operations for access windows. Continuous monitoring doesn't help or hurt here unless the RUL score gives the planner a time budget to work with — which is the point where the tool starts paying for itself.
- Route-based inspection (reduced, not eliminated): Some routes persist because not every asset warrants continuous monitoring, and because the physical presence of an RE doing a walk has value that no sensor array replicates. Two REs described maintaining "inspection-only" routes for lower-criticality assets.
What PdM tools get wrong about the RE's time
The tools that have highest adoption among the REs we spoke with share one characteristic: they make the RE's judgment central rather than trying to replace it. The tools that sit unused share a different characteristic: they assume the RE's primary problem is lack of data.
It almost never is. REs at experienced facilities typically have more raw data than they can process. What they lack is reliable signal from that data — a defensible ranking of "this bearing is heading toward failure faster than that one" that they can use in a conversation with operations or maintenance planning. A tool that surfaces more data without surfacing that ranking does not solve the problem.
We're not saying sophisticated dashboards are useless. We're saying that a dashboard is not a decision. The RE still has to make the decision, and if the tool doesn't make the relevant information legible quickly, it will not get opened in a busy morning.
The friction points nobody talks about
Three friction patterns came up in multiple conversations that rarely appear in vendor case studies:
Baseline drift after maintenance events. When a bearing is replaced or a motor is realigned, the asset's sensor signature changes. If the monitoring tool doesn't know a maintenance event occurred, it will generate spurious alerts against the pre-maintenance baseline. Two REs described spending meaningful time each month chasing alerts that turned out to be "changed machine, not degraded machine." The fix is a maintenance event log that feeds the baseline reset — obvious in principle, infrequently implemented.
Speed variation without speed compensation. Several monitored assets run at variable speeds — pumps on VFDs, compressors on variable loads. Vibration amplitude and bearing defect frequency (BPFO, BPFI, BSF) are all speed-dependent. A tool that isn't doing speed-normalization will generate both false positives (high amplitude at high speed, alarm fires) and false negatives (defect frequency shifts out of the monitored band at low speed). This is well understood technically, but the RE still has to explain it to every maintenance planner who questions a flagged alert.
Alert fatigue accumulating silently. In three of the six facilities, at least one monitoring system was described as "basically ignored." The path to that state was consistent: initial deployment with aggressive thresholds, early false alarms, skepticism from operations, no easy mechanism to tune thresholds, and gradual disengagement. The system doesn't fail dramatically — it just slowly stops being consulted.
What continuous monitoring actually changes about the job
The RE who has reliable continuous monitoring with a controlled false-alarm rate and a legible priority signal describes a different relationship with unplanned failure. Not zero unplanned failures — that's not a realistic claim for any system — but fewer catastrophic ones, and a sharply reduced number of "we had no idea that was degrading" moments.
The more meaningful change is in the planning conversation. When an RE can walk into a discussion about the upcoming 10-day turnaround and say "these three assets have RUL scores indicating they should be in this window; these two are fine for another three months," the conversation changes character. It moves from "what should we inspect during the shutdown" to "here's what we know needs to come out, and here's what we can defer." That's not a small shift. Turnaround scope is one of the highest-leverage decisions in a plant's maintenance budget.
That change doesn't happen because a tool presents more data. It happens when the tool earns enough trust that the RE will stake a planning decision on its output. Earning that trust takes time, and it starts with a false-alarm rate low enough that the signal doesn't get tuned out in the first 90 days.
That's the unglamorous reality of what PdM adoption actually looks like. Not a dramatic efficiency transformation — a gradual shift in what kind of information the RE brings to the planning table, and how much confidence they have in it.