A heat treater we work with runs three furnaces. Each one has fault contacts wired into a panel, and each one has had those contacts for years. The question was never whether the equipment knew it had a problem. The question was whether anyone found out at 2 AM on a Saturday, and for a long time the honest answer was that somebody found out Monday, from the scrap.
Building the thing that makes the phone ring is not the hard part. Almost none of the work is in the alerting. It is in deciding when not to alert, and in noticing what nobody wired.
The Hardware Is Usually Already There
Most plants are further along than they think. Fault contacts, thermocouple loops, and control-power relays already exist because the equipment vendor put them there. Adding a digital input module and pointing it at an MQTT broker on the plant network turns those contacts into a stream of state changes, and that stream is the whole input to the system.
Two details bite people on the first pass. Contacts are usually negative logic, so a closed, healthy contact reads as false and an alarm reads as true, which is backwards from every instinct you have while writing the decode. And the decode itself is a truth table, not a rule: three furnaces on twelve inputs is a manageable number of combinations, and every one of them should map to a named condition on purpose. We verified ours by extracting the decode logic and running all sixteen input states of one furnace through it under test, because reading a truth table and believing it is how you ship an alarm that never fires.
Deciding Who Gets Woken Up
An email is not an alarm at 2 AM. The escalation that works is a call chain: the system phones the first person on the list, and if the call is not answered it moves to the second, then the third, down through six names ending at whoever is guaranteed to pick up. SMS goes to the same list in parallel, email goes to everybody, and the call is the part that actually recovers the night.
One small piece of plumbing matters more than it sounds like. When a furnace faults, several contacts often change within the same second, and without a combiner that is four separate phone calls to the same person about the same event. Merging everything raised inside a two second window into a single notification is the difference between a system people trust and a system people mute.
Confirm timers belong in the same category. An inverter fault that clears itself in ninety seconds is noise, so that condition waits two minutes before it notifies. Anything that legitimately flickers needs a timer, and picking the length is a conversation with the maintenance manager, not an engineering decision.
Suppression Is Where These Systems Go Wrong
Two kinds of suppression are non-negotiable, and both of them are dangerous.
The first is context. "Furnace not turned on" is a normal, uninteresting fact at 9 AM on a Tuesday and a serious problem at 9 PM. So that condition is downgraded to no notification during weekday business hours and escalated to critical outside them. Every plant has three or four conditions like this, and getting them wrong in the safe direction means the on-call phone rings all day for nothing, which trains people to ignore it.
The second is repeat suppression: a held condition should alarm once, not every thirty seconds for eleven hours. This is obviously correct and it is also the single most common way a monitoring system quietly stops working. Suppress too broadly and you lose the second event. A fault that raises, clears, and raises again is new information, and it has to alarm again. We found ours over-suppressing exactly that case, which meant the condition that mattered most, an operator switching something off and back on overnight, was reported once and then never again.
The safety valve is a scheduled re-read. One job on a weekday-afternoon cron re-reads the last known state of every input and announces anything that is not normal, bypassing the repeat suppression entirely. If a condition has been sitting there quietly all day because the first alarm was acknowledged and forgotten, that job surfaces it before everyone goes home.
Put a Watchdog on the Watchdog
A monitoring system that has gone silent looks exactly like a plant with no faults. That is the failure mode to design for first: if the input module stops publishing for two minutes, that silence should itself generate an email to IT. Without it, an unplugged network cable buys you a week of perfect uptime reports and one very bad conversation.
Restarts are the same problem in miniature. Redeploying the flow drops monitoring for a minute or two, so every install needs a scheduled window rather than a quick fix at 4 PM. It is also worth knowing that in most of these tools, access to the editor is access to deploy, because there is no read-only mode. If a maintenance PC needs to see the dashboard, that is a URL. If someone needs the editor, that is a change to who can rewrite the alarms.
The Gap Is Always the Thing Nobody Wired
The most useful finding on this project had nothing to do with the code. A customer reported a quality miss that the system had not caught, and it turned out to be undiagnosable, because the component involved had no contact on it and there was no alarm log to review. Both halves of that are worth stating plainly.
Log every state change, permanently, from day one. The alarm history is what turns "it happened again" into a date, a duration, and a pattern. It costs almost nothing to write and it is the only evidence you will have when somebody asks what the equipment was doing at 3 AM six weeks ago.
Inventory what is not monitored, and say so out loud. A monitoring system creates an assumption of coverage. If the highest-consequence component in the cell has no sensor on it, the fact that everything else is watched makes that gap more dangerous, not less. Write the unmonitored list down, put it in front of the person who owns the equipment, and let them decide what to wire next.
Uptimize Solutions builds monitoring and operational apps around equipment that is already sending signals nobody is reading. If a fault on your floor is discovered by the next shift rather than by a phone call, see our custom operational apps or book a free workflow audit and bring the last unplanned downtime nobody can explain.