ThingsBoard Rule Engine: Set Up Alarms and Notifications

Build a sovereign, self-hosted IoT platform? WZ-IT designs, installs and runs ThingsBoard on your infrastructure - in the EU, no cloud lock-in. Explore the ThingsBoard platform

Alarms in ThingsBoard are created in the Rule Engine: incoming telemetry flows through a rule chain, a filter or script node checks the threshold, a Create Alarm node raises the alarm when the limit is exceeded, and a Clear Alarm node removes it once the value drops back. The notification (email, SMS, Slack, Microsoft Teams or webhook) is best handled by the Notification Center via an alarm trigger; alternatively a Send Notification or REST API Call node sends it straight from the rule chain. This guide walks through it step by step - with a concrete example rule chain, severity, status and a test. As of June 2026, ThingsBoard CE 4.3 (tag 4.3.1.3, Active LTS).

Table of contents

• How rule chains and nodes work
• The key alarm nodes
• Define a threshold alarm: example rule chain
• Alarm severity and status
• Notifications: email, Slack and webhook
• Notification Center vs. Send Notification node
• Test the alarm rule
• How we work at WZ-IT
• Further guides

How rule chains and nodes work

Every message a device sends to ThingsBoard passes through the Rule Engine (thingsboard.io). It is built from rule chains - directed graphs of nodes connected by named relations (e.g. True, False, Post telemetry, Created). Each tenant has a Root Rule Chain where every message starts; from there you can branch out to dedicated rule chains.

The Root Rule Chain typically begins with an Input node, followed by a Message Type Switch that splits messages by type (Post telemetry, Post attributes, RPC Request and more); a Save Timeseries node stores telemetry. For alarms we attach an extra branch to the Post telemetry output. If you do not have ThingsBoard running yet, see Install ThingsBoard; for what the platform does overall, read What is ThingsBoard?.

Scripts inside nodes are written by default in TBEL (ThingsBoard Expression Language), a lean sandboxed language. JavaScript is still selectable, but TBEL is faster and the recommended default.

The key alarm nodes

You only need a handful of nodes for alarms. The overview shows their role and main outputs:

The Create Alarm node is deliberately idempotent: if an active alarm of the same type already exists on the device, it only refreshes the alarm's end timestamp and details (output Updated) instead of creating a duplicate (output Created). So a permanently exceeded threshold produces exactly one alarm, not hundreds.

Define a threshold alarm: example rule chain

Goal: when the temperature exceeds 30 degrees, raise a High Temperature alarm with severity MAJOR; when it falls back below, clear it. In Rule chains, create a new chain or extend the Root Rule Chain:

1. Message Type Switch - continue from the Post telemetry output.
2. Filter node (type Script) named "Temp > 30?" with this TBEL filter:

return msg.temperature > 30;

3. Connect the True output of the filter to a Create Alarm node:
   • Alarm type: High Temperature
   • Alarm severity: MAJOR
   • Alarm details function (TBEL), counting the occurrences:

var details = {};
if (metadata.prevAlarmDetails != null) {
    var prev = JSON.parse(metadata.prevAlarmDetails);
    details.count = prev.count + 1;
} else {
    details.count = 1;
}
details.temperature = msg.temperature;
return details;

4. Connect the False output of the filter to a Clear Alarm node, also type High Temperature. The alarm then disappears automatically once the temperature is back below 30 degrees.

Schematically:

Input → Message Type Switch ──Post telemetry──► Filter "Temp > 30?"
                                                   │
                                          True ────► Create Alarm (MAJOR)
                                                   │
                                          False ───► Clear Alarm

For pure threshold logic without your own scripts there is an even simpler option: under Alarms → Alarm rules you define the condition, severity and clear condition declaratively in the UI, preferably at device profile or asset profile level rather than on individual devices (ThingsBoard, alarm rules). The rule-chain variant pays off as soon as logic is added (multiple keys, enrichment, time windows, external API calls).

Alarm severity and status

ThingsBoard has five fixed severities. In the Create Alarm node you pick a fixed value or enable a severity pattern that pulls the level dynamically from the message (e.g. ${msg.severity}):

The status of an alarm has two dimensions - active/cleared and acknowledged/unacknowledged - giving four values: ACTIVE_UNACK, ACTIVE_ACK, CLEARED_UNACK, CLEARED_ACK. A new alarm starts as ACTIVE_UNACK. When an operator acknowledges it in the dashboard it becomes ACTIVE_ACK; the Clear Alarm node sets it to CLEARED_*. These statuses also drive which notification triggers fire later.

Notifications: email, Slack and webhook

The modern, recommended path in ThingsBoard 4.3 and 4.4 is the Notification Center (menu item Notification center, thingsboard.io). It cleanly separates three building blocks:

1. Configure a delivery method (Settings): SMTP server for email, an SMS provider (Twilio, AWS SNS, SMPP), a Slack bot token or a Microsoft Teams connection.
2. Create a notification template: the content (with placeholders like ${alarmType}, ${alarmSeverity}) and the channels it is delivered through.
3. Create a notification rule with the Alarm trigger and assign the template plus a recipient group.

The available delivery methods at a glance:

A generic webhook (your own endpoint, n8n, Node-RED, ticketing system) is not handled by the Notification Center but by the REST API Call node in the rule chain: connect the Created output of your Create Alarm node to a REST API Call node that POSTs the alarm as JSON to your webhook URL.

Notification Center vs. Send Notification node

Both routes lead to a notification, with different characters:

• Notification Center (alarm trigger): declarative, GUI-based, fires automatically when an alarm is created, acknowledged, cleared or changes severity. Its escalation chains are especially strong: multiple recipient stages are notified in sequence with delays; if someone acknowledges the alarm first, later stages are skipped. This is the right choice for most alarm notifications.
• Send Notification node: sits directly in the rule chain and needs a notification template of type Rule node plus a recipient group. Useful when the exact trigger point depends on logic in the chain (e.g. only when count > 5 or after an enrichment step).

Rule of thumb: standard alerting via the Notification Center, special cases via nodes in the chain.

Test the alarm rule

Enable debug mode on the filter, Create Alarm and Clear Alarm nodes (open the node, turn on debug) - you then see the input and output of every message including the chosen relation. Then send test values over MQTT:

# Value above threshold -> alarm should be raised
mosquitto_pub -h localhost -p 1883 -u "ACCESS_TOKEN" \
  -t v1/devices/me/telemetry -m '{"temperature": 34}'

# Value below threshold -> alarm should clear
mosquitto_pub -h localhost -p 1883 -u "ACCESS_TOKEN" \
  -t v1/devices/me/telemetry -m '{"temperature": 22}'

Check under Entities → Devices → (device) → Alarms whether the High Temperature alarm appears with severity MAJOR and status ACTIVE_UNACK, and switches to CLEARED_UNACK after the second value. Visualise the readings and alarms in a dashboard - or combined with Grafana, see Grafana IoT dashboard with InfluxDB.

How we work at WZ-IT

We model alarms along your real processes: thresholds and hysteresis per device profile, sensible severities, clean clear conditions and escalation chains that reach the right people at the right time - without alarm fatigue from false positives. That includes tested rule chains, notification templates, your channels (email, SMS, Slack, Teams, webhook into the ticketing system) and operations with monitoring. All self-hosted on your infrastructure, as part of our ThingsBoard expertise and IoT platform development.

Further guides

• ThingsBoard expertise - consulting, integration and operations
• Install ThingsBoard - CE with Docker step by step
• What is ThingsBoard? - editions, architecture and protocols
• Grafana IoT dashboard with InfluxDB - visualise readings and alarms
• ThingsBoard pricing - editions, licences and real costs

Want alarms and notifications to run reliably in your IoT platform? Get to know us or take a look at our IoT platforms.