Excursion alerting is the set of rules layered on top of continuous temperature monitoring that decides when a reading, or a pattern of readings, turns into a notification sent to a person rather than just another data point written to a log. A monitored room or shipment can generate thousands of readings a day. Almost none of them should ever reach a phone or an inbox. Alerting is the filter that decides which ones do.
Get that filter wrong and it fails in one of two directions: too tight, and staff start ignoring alerts because most of them turn out to be nothing; too loose, and a real problem sits unnoticed until someone happens to check the log. Good alerting design spends most of its effort on that boundary, not on the sensors or the software around them.
Setting the threshold and the delay
A threshold set at the exact label claim, say the top edge of a 2-8°C range, fires constantly on ordinary events: a door opening, a defrost cycle, a delivery truck idling at the dock with its doors open for a few minutes. Working alerting design sets the threshold with a margin above the true limit and, just as importantly, requires the breach to persist for a set delay, commonly somewhere from ten minutes to half an hour, before it notifies anyone. That delay is deliberate. It is the difference between a system that reports every blip and one that reports only the excursions with a real chance of mattering. The same margin-and-delay logic separates a momentary reading from a sustained one: a five-minute high reading while a truck's rear doors sit open at a loading dock gets treated very differently from the same reading holding steady for an hour once the truck is back on the road.
Alarm rationalisation
Alarm rationalisation is the periodic review of every alert a system can generate, checking each one against how often it actually fires and whether anyone ever acts on it differently because of it. Alerts that fire constantly and get dismissed every time get their thresholds widened or get retired outright. Alerts that never fire get checked to see whether they are still watching for something real. The goal is a small set of alerts where every single one, when it fires, means something worth a person's attention, rather than a long list that mostly trains staff to stop reading notifications closely. Sites that run this review on a fixed schedule, monthly or quarterly rather than only after something goes wrong, catch a drifting threshold before it becomes a habit staff have already learned to ignore.
Escalation paths, and who is on call at 3am
A single alert to a single person is a weak design, because that person might be asleep, off shift, or simply not looking at their phone. A working system escalates: a first notification goes to whoever is closest to the problem, and if nobody acknowledges it within a set window, the system automatically moves up to a second contact, then a third, often ending with a manager or a remote monitoring service that covers hours the site itself does not staff. Facilities running unattended overnight depend entirely on this ladder working correctly, since there is no one physically present to notice a problem any other way. Acknowledgement usually has to be an explicit action, a tap in an app or a returned call, rather than a message simply marked as read, because a system that assumes silence means someone has it handled repeats the exact weak design escalation exists to fix.
An alert is not a decision
An alert only says a threshold was crossed for a defined duration. It does not say what the excursion means for the product, and it should never be treated as the decision itself. That judgement belongs to a documented response procedure written in advance: what to inspect, whether to quarantine the affected stock, whether to recalculate the cumulative thermal stress over the affected period, and who has the authority to release or reject the product afterward. The same procedure has to say who signs off on the outcome and where that decision gets recorded, so a batch released after an excursion has a written reason behind it, not just a timestamp showing an alert fired and was dismissed. Sites that skip this step end up with the same alert triggering a different, improvised response every time it fires, depending on who happens to be on shift when it does.
Limits of live alerting
Real-time alerting only works where there is a live connection back to a system that can send a notification. A single-use passive shipper carrying a temperature data logger with no cellular or network connection cannot alert anyone in transit; its record is read only after arrival, which makes it a retrospective check, not a live one. Building live alerting into a low-value, single-parcel shipment adds cost without changing what happens on that lane, since nobody can act on an alert mid-transit anyway. Alerting earns its cost on a facility, a fleet, or a connected high-value shipment where someone is actually in a position to respond before the product is compromised. The connection is what separates the two categories: real-time temperature monitoring is the plumbing a live alert travels through, and without it a logger can only ever report on what already happened, never on what is happening now.