Your first condition-based alert: making it trustworthy
The first few alerts teach a maintenance team what to expect from a new condition-based maintenance system. If those alerts repeatedly lead nowhere, investigating them starts to feel like a waste of time. Even if detection improves later, that trust can be hard to regain.
Condition-based maintenance can be powerful, but the best place to start is often a problem the team knows well and can verify. A few accurate, useful alerts can earn their trust and get your team excited to help shape the next ones instead of falling back on old routines.
Which failure should you try to detect first?
Resist the urge to instrument everything. Pick a single failure mode the team already recognizes and can explain from just a few readings, such as a tool that runs hot before it fails, or a motor that draws more current as it wears.
A good first failure mode has all of these:
- The team knows what the problem looks like and why it happens.
- It leaves a measurable trace in data you already collect.
- The warning gives someone time to check or act.
- A technician can verify what the alert found.
- There is a clear next step when it fires.
- It rarely produces false positives.
What can you measure without adding sensors?
More than most teams expect. The control system already reads a good deal for its own purposes. A first alert built on that costs nothing in hardware or installation time.
Before buying a sensor, investigate what the machine's programmable logic controller (PLC) already records:
- Run hours and cycle counts.
- Motor current or load, if measured.
- Temperatures, pressures, and flow rates.
- Fault codes, alarms, and changes in machine state.
MAJiK IoT Connect is a read-only solution that lets you safely browse and read those values. If you already track your operations with MAJiK Visual Factory, your equipment connection is already in place because it uses the same solution.
If an existing PLC signal tells you what you need to know, start there. Every new sensor adds complexity, along with another potential point of failure. Add one when the condition you care about is not already measured. You can connect the sensor to the PLC and read its value there, or have MAJiK IoT Connect read from the sensor directly.
How do you set a threshold you can trust?
Before sending alerts, test the threshold against your machine's history and overlay downtime events.
Normal peaks crossed 21 amps many times in this history. A higher threshold caught the rise that preceded the failure. For some conditions, breaching a threshold is enough, while others need the reading to persist or recur before it warrants an alert.
Adjust the threshold before any false alarms reach the maintenance team. For each replay, count:
- How often it would have fired.
- How many of those warnings lined up with known problems.
- How many fired during normal operation.
Who should the alert go to?
An alert sent to a shared mailbox can easily go unclaimed. Send it to the technician responsible for the asset, or to someone responsible for assigning the work across their team.
- Name an owner for the asset before the alert ever fires.
- Deliver it as a work order in a computerized maintenance management system (CMMS) such as Fiix or MaintainX.
- Include what changed and since when, so the first response is action, not investigation.
How do you maintain actionable alerts?
After each alert, record what the technician found and whether the warning helped them decide what to do. If it was a false alarm, find out what caused the reading and whether the rule can be adjusted without hiding a real problem.
Review failures that produced no alert, too. Did the condition appear in the data but fall short of the threshold, or was it never measured? Changes to equipment, tooling, products, or operating conditions can also change what "normal" looks like, so revisit alerts when those changes occur.
This feedback keeps the first alert useful and gives the maintenance team a role in shaping the next one. MAJiK Visual Factory keeps the equipment history you can use to review and tune alerts throughout the machine's lifetime. See how it works with controller data in condition-based maintenance.
Frequently asked questions
What should my first condition-based alert watch?
- A familiar failure mode that shows up in data you already collect. The team should be able to verify the warning and know what to check next.
How do I set a threshold I can trust?
- Test it against your machine's history. Count how often it would have fired, compare those times with known problems and downtime events, and adjust it to avoid normal variation.
Why do maintenance alerts get ignored?
- Repeated false alarms waste time, especially when the warning gives no clear next step or reaches nobody responsible for acting on it.
Who should receive the alert?
- The technician responsible for the asset, or someone responsible for assigning the work. Send it through a channel the team already uses, such as its CMMS.
Is this predictive maintenance?
- It can be part of a predictive maintenance program. This first alert does not try to forecast when a machine will fail. It flags a measured change so the maintenance team can check the equipment and decide whether to act before a breakdown.
Related: condition-based maintenance from PLC data, and push work orders to Fiix or MaintainX.
About the author
Adam Singer
Co-Founder, Project and Product Manager
Adam co-founded MAJiK Systems in 2014 and leads project delivery and product development, bringing the voice of the customer directly into the product roadmap. With a background spanning software engineering, industrial connectivity, and manufacturing operations, he has spent more than a decade working directly with manufacturers to turn real production challenges into practical, intuitive software solutions that are easy to understand, adopt, and use.