Picture a bearing on a critical pump without a redundant backup. It starts to wear, and the vibration monitoring system catches it. You have three weeks of warning, plenty of time to plan an intervention. So far, so good. The alert shows up on the distributed control system, and the board operator sees it. They check it out. Nothing looks wrong at the moment. The reading has ticked up, but it hasn’t crossed any hard limit, and a small shift in vibration is not grounds to pull a running pump. So they flag it up the line.

The shift supervisor looks at it and reaches the same conclusion. It’s a minor alert, not something worth stopping the plant over, and not something they have the authority to stop the plant over. It escalates again, this time to a general manager who oversees this plant along with several others. That manager may well have the skills to read the signal correctly, but not the context. A line item on a report or a two-minute phone call does not carry the operational feel that would tell them this particular alert, on this particular pump, is the one that matters. So it stays open, watched but not acted on.

Three weeks later, the bearing fails. Vibration spikes past the trip point, the programmable logic controller takes the pump offline, and the unit goes down unplanned. Now the plant is absorbing lost production time and scrambling a maintenance crew reactively, the exact scramble that three weeks of warning should have turned into a planned repair during a scheduled shutdown.

Notice what did not fail here. The sensor worked. The model worked. The alert fired with weeks to spare, and people saw it. What failed was everything after the alert: the part of the system that was supposed to turn a good signal into a timely decision. The alert climbed a ladder where every rung had less context than the one below it, and nobody on that ladder had both the authority to act and the ground-level knowledge to know they should.

Who was supposed to own that alert all the way to resolution? In a continuous process plant, or a batch plant for that matter, no one is assigned to one instrument or one system for the long haul. People rotate across sections, shift to shift, especially in larger facilities. The operator who first saw the alert may be on a different unit tomorrow, and once the shift ends, the open alert is, reasonably, no longer their problem.

Even when a plant assigns senior managers, maintenance leads or technical services staff to a specific unit or class of equipment, they are managing a complex portfolio of assets. They cannot fairly be expected to judge on the spot whether a small shift in a vibration trend warrants jumping the queue, and the trend alone does not indicate whether the bearing will fail tonight or next year. Without that answer, calling for an outage on a running plant is a hard case to make. The signal needed a champion who would carry it until someone acted. The plant’s own structure made sure it never got one.

We have gotten good at the sensing side of predictive maintenance: better vibration analysis, better thermal imaging, better models trained on more failure history. That progress is real. But a plant can have excellent sensors, an accurate model and a clean alert and still lose the asset, because nothing downstream of the alert was designed with the same care. The fix is something process engineers already know how to do; they just haven’t aimed it at this layer.

Where Programs Actually Break

Predictive maintenance programs fail in a handful of predictable ways: an alert with no clear owner, a threshold set for convenience rather than consequence, an action that needs sign-off from someone who never sees the alert. The program was built to detect. It was never built to decide.

This is not a knock on the people running these programs. Sensor selection, model accuracy and data quality are visible, measurable and easy to justify in a capital request. The response system — who owns what, who can act on what and how fast — is harder to specify, harder to budget for and easy to leave as an informal arrangement that works fine until the week it doesn’t.

Borrowing What You Already Know

The good news: You already have the tools to close this gap. Process engineers solve this class of problem every day on the physical side of the plant. A commissioning review will not let a system start up without a defined owner and a go/no-go decision. Layer-of-protection thinking refuses to accept a single point of failure. But the response layer behind a predictive maintenance alert has never been treated as the same kind of problem.

Five Checks for the Response System

Run these five questions against every alert category in your program. Each one names the discipline it borrows from, what to do and what a fuzzy answer costs you.

1. Ownership, borrowed from the commissioning discipline. Is every alert category tied to a specific, current role? Not a shared screen, not “whoever’s on shift,” not an escalation chain that sheds context at every step. Do this: Build a one-line-per-category register naming the accountable role. Make it a role, not a person, since roles outlast people. Update it whenever the org chart moves, and name who carries an open alert across a shift change so it does not reset to nobody at handover. Then test it: Pick three active alert categories and ask who owns each. If the answer takes more than a few seconds or two people disagree, ownership only feels defined. Fix this first; it is usually the cheapest gap to close.
2. Authority, borrowed from layered-protection thinking. When the alert reaches its owner, what can they do without waiting on someone else? If the honest answer is “escalate and wait,” the alert was forwarded, not received. Do this: For each category, write down the specific actions the first receiver is preauthorized to take, such as inspect, derate, remove from service or issue a work order at a set priority, and the dollar or risk limit below which they need no further sign-off. Scope it tightly if you must, but put it in writing before the alert fires, not in a scramble afterward. Every approval you can preauthorize is time handed back to an intervention window that usually runs days to weeks, not months.
3. Timing, borrowed from statistical process control and alarm management. What is the real intervention window for this failure mode, and what happens automatically if the owner misses it? Do this: Give each category an acknowledgment deadline and an action deadline, and configure the system so a missed deadline escalates on its own to a named second role instead of sitting silent. A threshold that fires weeks ahead of failure is worthless without a defined point where inaction triggers the next move. This is often the fastest fix of the five. You are usually writing down a number that already lives in someone’s head and wiring it into the tool.
4. Redundancy, borrowed from single-point-of-failure logic. If the primary owner misses the alert, misjudges it or is out that week, what is the second path? Most programs have exactly one route from signal to action, and if it breaks anywhere, there is no backup. Do this: Stand up a standing weekly review — 15 minutes is enough — where a second role scans every unacknowledged and open alert from the prior week and has the authority to reprioritize. That single recurring meeting is your second protection layer, and it costs a calendar entry, not a capital project.
5. Review, borrowed from management of change. When was this response system last checked, not for whether alerts are firing, but for whether it still works? Do this: Schedule a quarterly audit — monthly for your highest-consequence assets — that answers four questions in writing. Are the named owners still in their roles? Have thresholds been reviewed against current operating conditions? Did any failure in the period happen without a preceding alert? Did any preceding alert go unacted on? Put it on a recurring calendar with a named owner. Owners move on, thresholds drift and a program that was right at rollout decays without it.

Running the Checks: Two Failure Modes

The value of the five checks is that they locate the gap, and the gap is not always in the same place.

Take the missed alert from the opening. Ownership: No one was assigned to carry it to resolution. Authority: The people who could feel its weight could not stop the pump, and the person who could was too far removed to feel it. Timing: No deadline forced a decision; the alert just climbed. Redundancy: There was one path, straight up a chain that shed context at every level. Review: An audit against failure history might have shown that these alerts routinely escalated into silence.

Now the opposite problem: an alert nobody trusts. Picture a cooling tower conductivity sensor with a clear owner and a defined threshold. On paper, the program looks healthy. But suppose the threshold was set years earlier, before a process change raised baseline conductivity across the board. Now the alert fires constantly against normal variation, and the operator learns, reasonably, to wave it off. When a real excursion finally arrives, it is buried in months of noise. Here Ownership and Authority are both intact; the gap is entirely in Timing and Review. Nobody checked whether the threshold still meant anything, and no audit existed to catch it.

Same five questions, two very different break points. That is why you run them as a set rather than assuming a program that fires alerts is a program that works.