Controller-offline monitoring case study, food retail store
The controller went silent. KalderIQ noticed.
When the controller stopped reporting, the missing data became the alarm. KalderIQ raised it before the store’s morning started.
Download the two-page study (PDF)Sunday controller-offline alert
connectivity check, separate from controller alarms
treated as an event, not a quiet night
restored through remote reboot or dispatch
When the controller went dark, the data just stopped.
The two-page field studyDownload the PDFKalder by 
The problem.
The store’s logger showed the refrigeration controller as closed or malfunctioning, and current operating data stopped arriving. A controller that isn’t communicating can’t send its own temperature alarm.
What happened.
- Check that the controller is talking. KalderIQ monitors controller connectivity separately from the controller’s own alarms.
- Raise the silence as an alarm. A controller-offline alert fired at 6:55 a.m. on a Sunday.
- Restore visibility. The response is a remote reboot where possible, and a service visit where it isn’t.
The result.
A store that would have looked quiet was flagged as a store nobody could see. That is the difference between no alarms and no problems.
How the numbers were worked out.
The account records the alert time. It does not give the exact start of the outage, a measured detection delay or a financial outcome. The temperature chart in the PDF is a representative reconstruction. Losing communication doesn’t by itself mean refrigeration stopped. The customer’s name is withheld. Results are specific to this operation.
Seeing the same problem in your stores?
We’ll look at your equipment, your alarm response and what it would take to catch this earlier.