An alarm nobody answers is not monitoring
Sensors are the easy part of an IoT project. What decides whether the chiller failure at two in the morning costs a notification or a coolstore of product is who gets told, how, and what they are expected to do about it.
Most monitoring projects are scoped around the hardware. Which sensors, where they go, how they talk back, what the dashboard shows. All of that matters, and none of it is why monitoring fails.
It fails at the moment a reading goes out of range and the system has to make a person do something.
The three ways alerting breaks
Too many. Thresholds set tight on day one, every door opening triggering a temperature spike, every brief network drop raising a device offline alert. Within a month people mute the channel. Within two, the one alert that mattered is sitting unread among forty that did not.
To the wrong place. A dashboard nobody is looking at overnight. An email inbox checked at eight. A shared phone that is in a drawer. The alert fired correctly and reached nobody.
To nobody in particular. Sent to a group, so each person assumes someone else has it. Nobody acknowledges, nobody acts, and in the morning everyone saw it.
Design the response before the threshold
The useful question is not “what should we measure” but “when this goes wrong, who needs to do what, and how quickly?”
Separate warning from action. A reading drifting upward is worth knowing about during the day. A reading that means product is at risk needs a person now, whatever the hour. These should look and behave differently, and the second kind should be rare enough that it is never ignored.
Allow for the ordinary. Doors open, compressors cycle, deliveries arrive. Alert on a sustained condition, not a single reading, and the false alarms mostly disappear.
Name a person, then a second. Every serious alert goes to one named person on call, who has to acknowledge it. If they do not within a set time, it goes to the next person. Acknowledgement is the part most systems skip and the part that makes the rest work.
Say what to do. An alert that reads “Sensor 14 high” asks the person at two in the morning to work out what that means. “Coolstore 2 above 5 degrees for 20 minutes. Check the door is closed, then call the refrigeration contractor” gets the right thing done.
Monitor the monitoring
Sensors run out of battery, lose signal and fail quietly. A monitoring system that goes silent looks exactly like one reporting that everything is fine.
Alert on silence. A device that has not reported for longer than expected is itself an alert, routed to whoever looks after the system rather than the on call person.
Test it on purpose. Once a month, trigger a real alert and check it reaches the right phone, is acknowledged and escalates if it is not. It takes minutes, and it is the only way to know the chain works before the night it needs to.
Keep the history
The value of a monitoring system is not only the alarm. It is the record. A chiller whose temperature creeps a little higher each week is telling you about a failure months before it happens, and that trend is invisible without the data. For businesses with food safety or cold chain obligations, the record is also the evidence that product was held where it should have been.
Where this lands
When we build monitoring, we spend as much time on the response as on the hardware: who is on call, what each alert says, how it escalates, and how silence is detected. It is the least exciting part of the project and the part that decides whether it was worth doing.