In this guide 6 sections
Teams ignore sensor alerts because the rules fire on harmless spikes, carry no duration, go to everyone and need no reply. Fix the rules, not the people. Add a time condition, use rate of change, route by shift and escalate when nobody acknowledges.
Count what the alerts say before blaming staff
Export a month of alerts. Sort them by rule, by sensor and by hour. Then mark how many led to someone doing something.
You will usually find a handful of rules causing most of the noise. A chamber door-open spike that fires at once. A pump current limit set tight against normal start-up. A battery warning that repeats every hour until someone silences it.
People who ignore the phone buzz are being sensible. They learned that most alerts mean nothing. The system trained them. Talk to two operators as well. Ask which alert they trust and which they mute. Their answers are specific, and they point to the rules to fix first.
- Alerts per rule over the last month
- Share that got a human response
- Alerts that fired outside shift hours
- Repeats from a single unresolved cause
Rules with a limit but no duration
A single threshold crossing is a weak signal. Open the chamber door for a minute and the probe climbs above the limit, then drops back. The alert has fired, the event is over and the supervisor has learned nothing at all.
Add a duration. The reading must stay outside the limit for a stated time before the alert goes out. Pick the time from what the product or machine can tolerate, not from a round number.
Add a recovery rule too. Tell the team when it returns to normal, so they can stop checking.
Use rate of change where it fits
Some faults show in the slope before the limit. A cold room that loses temperature steadily at the rear probe is a compressor problem. A sharp short rise that recovers is a door.
A rate-of-change rule catches the first early. A duration rule filters out the second. Use both, on different alert levels.
Pair the sensor with context where you can. A door contact or a defrost cycle flag lets the system suppress the alert it already understands. Test each new rule on last month’s data. Replay it and count how many alerts it would have sent. That single check removes most surprises.
Alerts to everyone, and no one acknowledges
When an alert goes to a group chat of twenty people, each assumes another will act, and nobody owns it. Build a roster instead. The shift lead gets the first alert, a second person follows after a set delay and the manager comes in if neither replies.
Require acknowledgement with a short reason. Silence is a signal the system should act on by moving to the next person.
Include device health in the rules. A sensor that has stopped reporting is an alert too, but it belongs to the maintenance technician, not to the operator.
- Named person per shift
- Second contact after a set delay
- Manager as final step
- Offline sensors routed to maintenance
Rebuild the rules in small steps
Do not rewrite everything at once. Take the three noisiest rules, fix them and watch for two weeks. Count alerts and responses again.
Tell the shift teams what changed and why. A short note on the notice board is enough. People who see the noise drop start to trust the phone again.
Review monthly. Every alert that nobody acted on is either a bad rule or a missing step in the response, and both are cheap to fix once you can see them. Your next step: pull last month’s alert list today and mark the three rules that fired most.
Alert rule review sheet
Keep one rule per line on this single page sheet. Columns record the sensor, the limit, the duration, the rate-of-change setting, who receives it by shift, the escalation delay, alerts last month and how many got a response. A final column holds the decision: keep, change the duration, change the routing or remove.
Open a blank worksheet to printQuestions owners ask
What is alert fatigue?
It is when people stop responding because most alerts turn out to be harmless. The cure is better rules, with a duration, routing by shift and escalation, rather than a stern reminder to check the phone.
How long should an alert delay be?
Base it on what the product or machine can tolerate. A chamber door event may need a few minutes before it counts, while a pump overload may need seconds.
Should alerts go to a group chat?
Rarely. Name one person per shift, then escalate to a second person and a manager. A group message spreads responsibility until nobody holds it, and the alert sits unread.
How do we treat a sensor that goes offline?
Raise it as a device health alert to maintenance. A silent sensor means you have no data, which needs its own rule.