Cold Chain Temperature Monitoring: Making Sure the Alert Reaches a Human
Nearly every cold store is monitored. Far fewer have an alert path that reaches a person at three in the morning. That gap is the whole risk.
Cold chain monitoring rarely fails at the sensor. It fails at the alert path: a notification sent to a shared mailbox, an alarm muted after too many false positives, or a connection that was down so the message never left the building. The fix is an alert that reaches a named person, escalates when ignored, and is tested on a schedule.
Key takeaways
- A dashboard is not an alert; somebody has to be woken.
- Unacknowledged alerts must escalate automatically, or they rely on luck.
- Distinguish door-open events from real excursions or the alarm gets muted.
- If connectivity fails, monitoring continues but alerts stop leaving the site.
- Monitor the monitoring: a sensor reporting nothing should itself raise an alarm.
- Test the whole alert path on a schedule, including out of hours.
Cold chain temperature monitoring: the failure is almost never the sensor
When a temperature excursion turns into a written-off consignment, the post-mortem usually finds that the monitoring worked perfectly. The probes recorded the drift accurately, the system logged it, and the graph afterwards shows the whole event in detail. What failed was everything between the reading and a human being who could have acted.
This is worth stating plainly because monitoring is sold on sensor accuracy and reporting features, and those are rarely the weak point. The weak point is the chain of things that must all work at three in the morning: the sensor reports over a network, the system evaluates a threshold, a message leaves the building over a connection, a notification reaches a device, and a person wakes up and understands what it means.
Any one of those breaking produces the same outcome as having no monitoring at all, with the added disadvantage that everybody believed they were covered.
It also explains why buying a better monitoring system rarely fixes a firm that has had an incident. The new system will have the same alert path problem as the old one, because the alert path was never the product being compared. It sits in the infrastructure around the product, which is nobody's headline feature.
What an alert has to do
An alert that works has four properties. It reaches a named individual, not a shared mailbox or a screen in an office nobody occupies overnight. It arrives by a channel that actually interrupts: a telephone call or a push notification with a sound, rather than an email that will be seen at eight in the morning.
It escalates. If the first person does not acknowledge within a defined period, it goes to a second, and then a third. Without escalation the system depends on one phone being charged, in range and audible, which is not a control so much as a hope.
And it is proportionate, meaning it fires for events that matter and not for every door opening during a picking round. This is the property most often got wrong, and its failure mode is the worst of all: alerts that fire constantly get muted, forwarded to a folder, or ignored by habit, and then the real one arrives and is treated like the others.
- Named recipient, not a shared or role mailbox.
- A channel that interrupts: call or push with sound, not email alone.
- Automatic escalation to second and third contacts on no acknowledgement.
- Thresholds and delays tuned so routine door events do not fire alarms.
Tuning thresholds so people keep trusting the system
Most false alarms in a cold store are not faults. They are doors opening, pickers working an aisle, a defrost cycle, or a probe near an air curtain reading the transient rather than the product. A system configured on instantaneous readings will fire during all of them.
The usual remedy is a time-over-threshold condition: an alert fires when a reading stays out of range for a defined period rather than the instant it crosses. That period comes from the thermal behaviour of the product and the store, which is a question for your quality team and monitoring supplier rather than for IT, but the principle matters to anyone designing the alert path.
Where practical, separate warning from critical. A warning that the store is drifting, sent quietly during working hours, lets somebody investigate before it becomes an event. A critical alert that wakes people is reserved for conditions that genuinely require action now. Two levels are usually enough; more than three and nobody remembers what they mean.
Review the thresholds after the first quiet month. Almost every installation is tuned optimistically at commissioning and then generates more noise than expected once real picking patterns start, and the moment to correct that is before anyone has started ignoring the alerts rather than after.
When the internet fails, the alerts stop and the monitoring does not
An internet failure is the scenario worth designing for specifically, because it is silent. If the site loses connectivity, sensors keep reading, the system keeps logging, and the dashboard will show a complete record afterwards. What does not happen is any alert leaving the building. Everyone believes they are covered, and nobody is.
There are two defences and both are worth having. A second path out for alerting, usually cellular and often dedicated to the monitoring system rather than shared with the office connection, so a primary line failure does not silence notifications. And local alerting that does not depend on the network at all: an audible alarm on site, and notification to somebody physically present if the operation is staffed.
Our IT support for cold chain logistics page covers how that second path is built, and office network setup covers failover generally. In this application the failover is protecting stock rather than productivity, which usually changes the budget conversation.
Monitoring the monitoring
A sensor that stops reporting looks, to a naive system, exactly like a sensor reporting nothing wrong. That is a dangerous equivalence, and it is why any serious arrangement includes a heartbeat: if a device has not reported within an expected interval, that absence itself raises an alert.
The same applies to the system as a whole. A monitoring appliance that has crashed, a gateway that has lost power, or a network switch that has failed will all produce a quiet dashboard, which is indistinguishable from a good night unless something is watching for silence.
This is squarely IT's responsibility rather than the monitoring supplier's, and it is cheap to arrange. The infrastructure monitoring that watches your switches and connectivity can watch the monitoring gateway too, and alert when it stops responding.
Heartbeat intervals should be short enough to matter. A device that checks in hourly can be dead for fifty-nine minutes before anything notices, which in a freezer recovering badly is a long time. Match the interval to how quickly the product would actually be at risk, not to whatever the default was.
The record, and what it has to withstand
The second purpose of monitoring is evidence. When a consignee rejects a shipment or an authority asks how product was handled, the temperature record is what settles it. That record needs to be complete, attributable, tamper-evident and available long after the shipment moved.
The common weakness is that it lives only on the appliance in the store. That device is in the harshest environment on site, it is the thing most likely to fail, and if it is lost the evidence goes with it. Replicate the data off the device and off site, retain it for a period set against your licensing and contractual obligations rather than at a default, and include it in a backup that has been restored from.
For pharmaceutical work in the UAE the licensing expectations sit with the Ministry of Health and Prevention alongside whatever the product owner specifies. Our backup that actually restores guide covers the testing discipline, which matters more here than almost anywhere, because the first time you produce this record is the first time anyone examines it closely.
Where product moves between sites and onward flights, the transactional record usually runs through Dubai Trade while the temperature record stays with you, and the two need to be reconcilable by consignment reference. Agreeing that reference convention early saves considerable difficulty when a specific shipment is later queried.
Testing the path, not the sensor
Sensor calibration is scheduled, documented and taken seriously in every competent operation. The alert path usually is not tested at all, which is odd given it is the part that fails.
A quarterly test is enough and takes fifteen minutes. Trigger a test condition, confirm the alert arrives on the named person's phone, leave it unacknowledged and confirm it escalates to the second contact. Do it once out of hours rather than always at eleven in the morning, because the out-of-hours path is the one that matters and is the one most likely to have quietly broken.
Record the result. That log is useful operationally and it is also the thing that demonstrates diligence if an incident is ever investigated. A firm that can show it tested its alerting every quarter is in a materially different position from one that cannot.
Include the people in the test, not only the technology. The person who receives the alert should be able to say what they would do next: who they call, whether they attend site, and what they do about the stock. An alert that arrives perfectly and is not understood has still failed.
Who owns what
The boundary that works: sensors, probes, calibration and the monitoring application belong to the specialist supplier, because calibration carries obligations and the application is theirs. The network the sensors report over, the connectivity that carries alerts out, the power that keeps both running, the heartbeat monitoring and the off-site retention of the data belong to IT.
Write that split down, including who is called when an alert path fails rather than a chiller. The failure mode without it is familiar: the monitoring supplier says the network dropped, IT says the gateway crashed, and the operation spends a day without alerting while two suppliers discuss it.
Agreeing it at installation costs nothing, and our IoT work is that infrastructure half of the split. Agreeing it during an incident costs whatever was in the store. Our managed IT support service covers the infrastructure side and the monitoring of the monitoring.
Frequently asked questions
No. A shared inbox at three in the morning belongs to nobody, and email does not interrupt. Alerts should reach a named individual on a channel that wakes them, such as a call or a push notification with sound, and escalate automatically to a second person if unacknowledged within a defined period.
Use a time-over-threshold condition so an alert fires only when a reading stays out of range for a defined period, rather than the moment it crosses. The period comes from the thermal behaviour of the product and store, which your quality team and monitoring supplier should set. Separating warning from critical levels also helps.
Monitoring continues and alerts stop leaving the building, which is a silent failure and the scenario most worth planning for. The defences are a second path out, usually cellular and often dedicated to the monitoring system, plus local audible alarming that works without any network at all.
Only if something is watching for silence. A sensor reporting nothing looks the same as a sensor reporting no problem. A heartbeat check that raises an alert when a device has not reported within an expected interval closes that gap, and the same principle applies to the gateway and the monitoring appliance itself.
Not only on the appliance in the store, which sits in the harshest environment on site and is the most likely thing to fail. Replicate off the device and off site, retain it against your licensing and contractual obligations rather than a default setting, and include it in a backup you have actually restored from.
Quarterly is reasonable, and it takes about fifteen minutes. Trigger a test condition, confirm arrival on the named phone, then leave it unacknowledged to confirm escalation works. Do it out of hours at least once a year, since that is the path that matters and the one most likely to have broken unnoticed.
Whoever the written split says, which is why it needs writing down before an incident. Sensors, calibration and the monitoring application sit with the specialist supplier. The network, connectivity, power, heartbeat monitoring and off-site data retention sit with IT. Without that agreement, an incident becomes a discussion between suppliers.
Written by Srinivasan Ramachandran, Founder, Listonics · Published Sep 28, 2026 · Last reviewed October 11, 2026 · 2,027 words
