Your car’s check engine light tells you your vehicle has a problem. It doesn’t tell you where, how bad it is, or what to do about it. Most monitoring programs work the same way.
And that’s the issue. An alert by itself isn’t all that useful. “Something’s wrong with pump four” doesn’t give your team much to act on. They still have to figure out how bad it is, how urgent it is, and what they actually need to do. That investigation takes time, and it only happens if they trust the alert enough to bother with it.
The alert is the easy part. Everything that comes after is where the value is.
Notification vs. prescription
There’s a big difference between a notification and a prescription. A notification says something’s wrong. That doesn’t add much to your team’s day. A prescription indicates bearing wear at pump number four; here’s the evidence and what to do about it.
One creates work. The other clarifies it. And that distinction is the whole difference between predictive maintenance and prescriptive maintenance.
What a prescriptive alarm actually contains
When we send an alarm at Augury, it isn’t just a notification. It’s everything your team needs to act, built around four things.
First, the diagnosis. What’s actually wrong with the equipment? Is it bearing wear? Is it misaligned? Is it a loose mounting bolt creating structural looseness? Your team shouldn’t have to reverse-engineer the problem from a vague alert.
Second, the evidence. . Show me the graphs and empirical data proving why I need to act on this alarm. Trust comes from evidence, not assertion.
Third, the action. Show me exactly what to do to fix the problem. Do I need to realign the pump? Snug down the mounting bolts? Replace a component? A good alarm tells your team what the repair actually is.
And fourth, the urgency. Tell me the severity, and how quickly I need to act to keep this equipment from failing. Not every problem needs an emergency response, and not every problem can wait for the next planned window. Knowing the difference is what lets your team plan.
What prescriptive maintenance looks like in practice
Here’s a real example from an Augury customer, a plastics manufacturer running a blow molding machine with a monitored gearbox.
The alarm was originally generated for a temperature increase at bearing three, a rapid rise to around 55°C (roughly 131°F). That kind of rapid climb signals a significant problem developing quickly, so we escalated the machine straight to danger, meaning the customer needed to look at it within 24 hours.
When they went out to inspect the machine, they found no oil left in the gearbox. It was all on the ground. And the vibration data told the same story: a gradual increase in RMS acceleration over a short window, paired with a mild increase in structural vibration. On its own, each signal is a data point. Paired with the temperature, it tells a clear story. The acceleration increase drove the temperature rise, causing undue friction and rubbing in the gearbox gears.
The customer investigated, found the low oil, replaced it, eventually replaced the gearbox, and got the machine back into an acceptable state. That’s what a prescriptive alarm makes possible:not just “something is wrong,” but go look at this specific point on this specific gearbox and see the heat source at bearing three for yourself.
An alert without a plan is just noise
Every alarm should meet the same standard: not just flagging a problem, but pointing your team straight to it, with the evidence and the fix already in hand. That’s the difference between a monitoring program your team tolerates and one they actually trust.
Watch Episode 3 of Five Minute Maintenance to learn more
Five Minute Maintenance is a monthly series for reliability and maintenance teams, breaking down the concepts and frameworks that help you run a smarter program. Subscribe so you don’t miss the next episode.
Ready to see what prescriptive maintenance looks like for your team?
