Monitoring commercial fridges and freezers remotely
Remote monitoring is straightforward to buy and easy to get wrong. The difference between a system that saves stock and one that gets muted is mostly in alert design, not hardware.
The problem
Refrigeration fails at the least convenient time: overnight, over a bank holiday weekend, or in the fortnight when the site manager is away. Businesses that lose a fridge of stock usually had no way of knowing until someone opened the door. The problem is not that monitoring is hard to buy — it is that a monitoring system nobody trusts is functionally the same as no monitoring at all.
What remote monitoring actually consists of
Four parts, and it is worth understanding them separately because different suppliers are strong at different ones.
Most disappointment comes from the third and fourth parts. Sensors are a commodity; alert routing and the ability to answer an auditor are not.
- Sensors in or on each appliance, reporting on an interval
- Connectivity to get readings out of the building — Wi-Fi, a dedicated gateway, or cellular where neither is reliable
- Alert rules that decide what is worth waking someone for, and who that someone is
- History you can export without asking the supplier for it
Sensor placement decides your false alarm rate
Put a sensor directly in the airflow of the evaporator fan and it will read colder than the food. Put it in the door shelf and it will spike every time the door opens. Neither reading is wrong; both are useless as a basis for alerting.
Place sensors where the product sits, at the height most of the stock occupies, away from the fan outlet and the door. In freezers, a probe in a buffered solution smooths out short-term swings and gives you something closer to product temperature than air temperature. This matters most in medical storage, where the difference determines whether stock has to be discarded — see vaccine and pharmacy fridge monitoring.
Designing the out-of-hours response
Everyone agrees alerting should work at 3am. Fewer businesses decide in advance what happens next. Before going live, answer three questions in writing: who is called, what can they actually do at that hour, and at what point does it become someone else's problem?
A realistic pattern for a single site is a first alert to the duty manager's phone, escalation to the owner or area manager if unacknowledged after fifteen minutes, and a documented fallback — move stock to the working unit, or call the refrigeration engineer whose number is on the alert itself. Systems that include the action in the alert get acted on; systems that just say "Fridge 3 is warm" get silenced.
Covering more than one site
Once there are several venues, the useful question changes from "what is the temperature" to "which site needs attention right now". A per-site dashboard that someone has to visit will not be visited. What works is one view across the estate that surfaces exceptions, with alerts routed to local staff and a weekly summary to whoever is accountable for the group.
That structure also makes underlying problems visible. A unit that recovers slowly every single day is not yet an incident, but it is a failure being scheduled. Seeing it across sites is how you catch it. A three-site deployment structured this way is described in the cold chain monitoring case study.
Do you need a building management system?
Usually not. A BMS makes sense when you are already controlling plant — HVAC, refrigeration packs, lighting — and want monitoring integrated with control. For a business that simply needs to know when a fridge is failing, a standalone sensor deployment is faster to install, cheaper to run and easier to move when the kitchen gets refitted.
The exception is a large estate with existing controls and an engineering team. There, feeding sensor data into what already exists beats introducing a second system, and we integrate rather than replace — the API is described on the temperature monitoring API.