Start with the decision the alert should support
Good IoT alert design starts with a clear operational next step. When a temperature reading crosses a limit and a notification reaches your team, who takes responsibility
The answer might be to inspect equipment, check whether a reading is valid or investigate a connectivity issue. It should be specific enough for the responsible team to recognise its next step.
“Temperature is high” describes a condition. “Check the latest temperature trend and follow the inspection procedure for this asset” gives the recipient a starting point.
If there is no useful response, consider whether the event belongs in a dashboard or a periodic report instead. Keep immediate notifications for situations where timely attention serves a defined purpose.
Define the trigger in operational terms
A threshold alone does not describe the full situation. Agree on the conditions that justify attention before implementing the rule.
Consider duration and operating state
Would a brief excursion require the same response as a persistent deviation? Should the rule apply during startup, planned maintenance or normal operation?
Where appropriate, consider requiring a condition to persist before notifying someone. Validate any delay against the process: filtering out short fluctuations is useful only when the resulting response time remains acceptable.
Check whether the data is usable
Include units and measurement timestamps in the alert context. A recent notification can contain an old measurement, particularly when devices reconnect and transmit buffered data.
Also distinguish an abnormal reading from a missing reading. A device that stops reporting creates uncertainty about its condition; missing data does not establish that the monitored process has failed.
Give every alert an owner and a first action
Sending a message to a shared inbox leaves an important question open: who takes responsibility?
Define a primary responder, a backup and the circumstances that require escalation. These responsibilities may sit in an existing maintenance process or service workflow. Document them alongside the alert rule.
The first action should be something the recipient can perform within their role and permissions. An operator might review a trend and contact maintenance; a technician might follow an approved diagnostic procedure.
Avoid instructions that assume a confirmed cause. An unusual reading can justify investigation without proving which component needs repair.
IoT alert design: write notifications that guide action
A practical message should help the recipient answer five questions:
- Which asset and location need attention?
- What was observed, and when?
- Why does this condition require attention?
- Who owns the response?
- Where should the recipient begin?
An illustrative notification
The following is a fictional example, not a customer case or a predefined thethings.iO alert template:
Warning: Cooling unit CU-07 — Site B
Latest reading: 9°C at 14:32 UTC.
Condition: above the configured 8°C limit for 10 minutes.
Owner: Site B operations.
Next step: review the temperature trend and follow the approved inspection procedure.
Reference: asset dashboard and procedure CU-07.
The values and duration are illustrative, not recommended operating limits. Each deployment needs thresholds and procedures appropriate to its equipment and process.
Plan reminders, escalation and recovery
Define what should happen after the initial message. Should the team receive a reminder while the condition persists? When should a backup responder become involved? What evidence allows the event to be closed?
Keep acknowledgement, recovery and resolution separate. Acknowledgement means someone has taken responsibility. Recovery means the monitored condition has returned within its defined range. Resolution means the required follow-up is complete.
For values that fluctuate around a boundary, consider separate trigger and recovery thresholds. This approach, called hysteresis, can help avoid repeated state changes around one limit. Whether it is appropriate depends on the process and implementation.
Choose the channel after defining the workflow
thethings.iO supports configurable alerts and notification channels based on device thresholds or events, including email, SMS, WhatsApp and Telegram. Its Cloud Code Triggers documentation also describes triggers that can send alarms and call external web services.
For a broader view of how these capabilities fit together, explore thethings.iO platform features, including dashboards, alerts and Cloud Code.
Choose channels according to urgency, working conditions and team coverage. Email may suit a detailed review; a mobile notification may suit a responder away from a desk. Channel availability alone does not establish that a message will be acknowledged or acted on.
Treat ownership, escalation, acknowledgement and closure as workflow requirements to validate for the deployment. They may require additional logic or integrations; do not assume they are included simply because notifications are available.
Test the response before expanding the rules
Pilot one alert with the people who will receive it. Test an abnormal reading, a brief fluctuation, missing data and a return to normal. Check both message delivery and whether recipients understand the expected response.
Record whether alerts led to action, needed clarification or repeated information about an existing issue. Use those observations to refine the rule, message and routing.
Planning an IoT alerting workflow? Contact thethings.iO to discuss your devices, notification requirements and the operational steps your team needs to support.nts and the operational steps your team needs to support.
