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.

Alarm rules can only be created and managed by Tenant Administrators. Customer-level users do not have access.

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 lets you manage all alarm rules in the system — for individual entities and for profiles.

Alarm rules can be created for Devices, Assets, their profiles, or Customers — the process is the same for all entity types. For an overview of alarm concepts, states, and severity levels, see Alarms.

1. Open the Monitor ⇾ Alarms page from the left-hand menu.
2. Go to the Alarm rules tab.
3. Click the + Add alarm rule 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.

If an alarm is already active and a new trigger fires at a higher severity, ThingsBoard upgrades the existing alarm’s severity instead of 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 as 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 supply the schedule as a JSON object via an attribute or telemetry key instead of a fixed 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 },

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 the 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 ${argumentName} placeholders. For details, see Additional Info.
• 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. Use it for operator notes, troubleshooting steps, documentation links, or a zone ID.

The field takes plain text with ${argumentName} placeholders. When the alarm fires, every placeholder that matches an argument of the rule is replaced with that argument’s current value. A placeholder that matches no argument stays in the text unchanged.

The rendered text is stored under a single data key in the alarm’s details. With arguments named RSSI and rssiThreshold, this field

RSSI ${RSSI} dropped below the threshold ${rssiThreshold}

produces these alarm details:

{
  "data": "RSSI -65 dropped below the threshold -70"
}

For how notification templates use this value, see Template parameters.

To store each value under its own key, create the alarm from a rule chain with the Create alarm node instead of an alarm rule. For details, see Enrich alarms with details.

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

Configure with AI lets you create and manage alarm rules by describing what you want in plain language, instead of manually filling in arguments, trigger conditions, and severities. It’s powered by the AI Assistant available throughout ThingsBoard — see that guide for how to write effective prompts and how the Assistant works in general.

It’s useful whenever you know what condition should raise an alarm but don’t want to configure the trigger logic by hand — for example:

• Creating a new alarm rule for a device or asset profile from a plain description of the condition
• Setting up a device or asset inactivity alarm
• Adjusting an existing rule’s thresholds, severity, or clear condition
• Getting suggestions for alarm rules that make sense for a given profile

Workflow

1. On the Monitor ⇾ Alarms ⇾ Alarm rules page, click Configure with AI to open the AI Assistant panel.
2. Describe the alarm rule you want in the chat — the condition, the entity or profile it applies to, and the severity, e.g. “Create an alarm rule that triggers a warning when a device stops sending telemetry for more than 10 minutes.” Use the suggested prompts if you’re not sure where to start.
3. The Assistant explains its plan, then proposes the change — such as creating, updating, or deleting an alarm rule — as an approval card describing exactly what will happen.
4. Click Approve to apply it, Deny to reject it, or Approve all further actions to apply the rest of the plan without confirming each step individually.
5. Keep the conversation open to refine the result — reply with follow-up instructions to adjust the condition, severity, or target profile instead of starting over.

Best Practices

• Describe the condition and the outcome you want, not the specific arguments or trigger mode — the Assistant picks the right configuration.
• Name the device, asset, or profile clearly so the Assistant applies the rule to the right target.
• Include thresholds, durations, and severities upfront to skip a round of clarifying questions.
• Review each proposed rule before approving, especially before using Approve all further actions.

Limitations

• Changes are proposed, not applied silently: each one needs your approval, unless you approve all further actions in that chat.
• The Assistant’s summary states exactly which entity, telemetry key, condition, and severity the rule uses — review it before approving to confirm it matches what you intended.

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 entity owners hierarchy: Propagates the alarm up the entire ownership chain: Asset ⇾ Customer ⇾ Tenant. All higher-level owners see the alarm even without a direct relation to the originator. Useful for B2B platforms with nested customer structures and MSP deployments.

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 are listed on the Monitor ⇾ 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:

1. Go to Monitor ⇾ Alarms ⇾ Alarm rules.
2. Click Export (download icon) in the rule’s row.

To import a rule:

1. Go to Monitor ⇾ Alarms ⇾ Alarm rules.
2. Click + Add alarm rule ⇾ 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.