Alarm Rules

Alarm rules define when alarms are created, updated, and cleared. Each rule specifies the data sources to monitor, the conditions that trigger or clear an alarm, the severity level, and how the alarm propagates through the entity hierarchy.

Rules can be defined at the level of a device, asset, their profiles, or a Customer. For an overview of alarm concepts, states, and severity levels, see Alarms.

When a message arrives (telemetry update, attribute change, or inactivity event), ThingsBoard evaluates every alarm rule whose arguments match the incoming data:

The Alarm rules page allows you to centrally manage all alarm rules in the system — both for individual entities and for profiles.

1. Open the Alarms page from the left-hand menu.
2. Go to the Alarm rules tab.
3. Click the + button in the top-right corner.
4. Select Create new alarm rule from the dropdown menu.

The General section sets the basic identity of the alarm rule:

• Alarm type: The name and unique identifier of the alarm, like High Temperature. ThingsBoard uses the alarm type to decide whether to create a new alarm or update an existing active one.
• Entity type: The target entity or entity profile where the rule applies.

Enabling debug mode lets you track events, states, and errors during rule execution.

Before defining alarm conditions, add at least one argument — a data source the rule evaluates.

Click Add argument and configure:

Entity type determines where the argument value comes from:

Argument type determines what kind of data the argument represents:

Argument name is the identifier used in conditions and formulas, like temperature or maxThreshold.

After filling in all fields, click Add.

Trigger conditions define when an alarm is created and at what severity. Click Add trigger condition.

Select the severity level for this trigger condition. For level descriptions, see Alarm severity.

When an existing alarm is active and a new trigger fires at a higher severity, ThingsBoard upgrades the severity of the existing alarm rather than creating a new one.

The condition is the logical expression that determines whether an alarm is created or updated.

Click Add condition, then click Add argument filter and configure:

• Argument: The variable to compare, like temperature.
• Value type: The data type: Numeric, Boolean, String, etc.
• Filters: One or more comparisons. For each filter, set:
  • Operation: equal, not equal, greater than, less than, missing for, and others.
  • Value source: Static for a fixed value, or Dynamic to use the value of another argument.
  • Value: The value to compare against.

When multiple filters are present, combine them with AND (all must be true) or OR (at least one must be true).

Conditions can be written manually or using TBEL script functions for advanced expressions.

The schedule defines when a trigger condition is allowed to fire. If the condition becomes true outside the allowed window, no alarm is created.

Static schedule offers three modes:

Dynamic schedule lets you provide a schedule JSON object through an attribute or telemetry instead of a static configuration. This is useful when the schedule varies between devices or customers. To use dynamic mode, go to Schedule, choose Dynamic mode, and select the argument that contains the schedule JSON.

Schedule JSON examples:

Active all time:

{ "type": "ANY_TIME" }

Active on Tuesday and Thursday, full day, Europe/Kiev timezone:

{
  "type": "SPECIFIC_TIME",
  "daysOfWeek": [2, 4],
  "startsOn": 0,
  "endsOn": 0,
  "timezone": "Europe/Kiev"
}

Custom schedule, every day, full 24 hours:

{
  "type": "CUSTOM",
  "timezone": "Europe/Kiev",
  "items": [
    { "dayOfWeek": 1, "enabled": true, "startsOn": 0, "endsOn": 0 },
    { "dayOfWeek": 2, "enabled": true, "startsOn": 0, "endsOn": 0 },
    { "dayOfWeek": 3, "enabled": true, "startsOn": 0, "endsOn": 0 },
    { "dayOfWeek": 4, "enabled": true, "startsOn": 0, "endsOn": 0 },
    { "dayOfWeek": 5, "enabled": true, "startsOn": 0, "endsOn": 0 },
    { "dayOfWeek": 6, "enabled": true, "startsOn": 0, "endsOn": 0 },
    { "dayOfWeek": 7, "enabled": true, "startsOn": 0, "endsOn": 0 }
  ]
}

Field reference:

• timezone: Time zone for interpreting the schedule.
• daysOfWeek: Days in numeric format (1 = Monday, 7 = Sunday).
• startsOn / endsOn: Milliseconds from the start of the day. Setting both to 0 means the full day.

The clear condition defines when ThingsBoard automatically transitions an alarm to Cleared state.

Without a clear condition, the alarm never clears automatically and can only be cleared manually via the UI or API.

Click Add clear condition and configure:

• Condition: The expression that determines when the alarm is resolved, like temperature ≤ 30. Uses the same filter and argument configuration as trigger conditions.
• Condition type: Simple, Duration, or Repeating. See Condition types for behavior details.
• Schedule: When the clear condition is allowed to fire. The alarm is not cleared if the condition is met outside the allowed window.
• Additional info: Extra data stored in Alarm Details at the moment of clearing. Supports ${attributeName} placeholders.
• Mobile dashboard: The dashboard that opens when viewing a cleared alarm in the mobile app.

The Additional info field stores extra contextual data alongside the alarm, visible in the alarm details view. It supports dynamic placeholders using ${attributeName}.

Use it for data like operator notes, troubleshooting steps, documentation links, or a zone ID.

The Mobile dashboard field specifies which dashboard opens in the ThingsBoard mobile app when a user navigates to the alarm, giving field engineers immediate access to relevant widgets and diagnostics on-site.

Propagation controls at which level of the entity hierarchy the alarm becomes visible. For a conceptual overview, see Alarm propagation.

Propagate to related entities: The alarm becomes visible to all entities related to the originator, regardless of relation type. In a Device → Office → Building chain, all three entities see the alarm.

Propagate to the owner (Customer / Tenant): Makes the alarm visible to the direct owner of the originator without requiring explicit relations.

Propagate to Tenant: Makes the alarm visible at the Tenant level regardless of ownership or relations. Use this when the Tenant Administrator needs visibility into all alarms across the infrastructure.

Alarm rules appear in the table on the Alarms → Alarm rules page. The table shows alarm type, target entity, severity levels, and whether a clear condition is configured.

Each rule row has an action bar:

Click a rule row to view its full details. To edit a rule, click Edit (pencil) in the details panel, make your changes, then click Apply (checkmark) to save.

To export a rule, go to Alarms → Alarm rules and click Export (download icon) in the rule’s row.

To import a rule:

1. Go to Alarms → Alarm rules.
2. Click + and select Import alarm rule.
3. Drop the JSON file into the import dialog or select it manually.
4. Click Import.
5. Specify the entity or profile the rule applies to.
6. Click Add.

The rule becomes active immediately after saving.

The following tutorials walk through common alarm rule configurations, from basic thresholds to dynamic schedules. Each example builds on the previous one using a Thermometer device.

For full step-by-step instructions, see Alarm rule tutorials.