What you’ll see on the form
- Alarm Name: A short, descriptive name that helps you and your team understand what this rule monitors.
- Description: A longer, optional note describing the purpose of the alarm and suggested actions when it fires.
- Alarm Type: Choose Single Metric, Group Comparison, or Log Threshold. Log Threshold alarms evaluate matching log volume, unique attributes, or numeric measures.
Define the metric and its scope
Pick the metric, then which devices it watches with Where.- Topic and Field: the stream and the value to evaluate (for example
temperature). The app suggests topics and fields your devices publish. - Where: conditions on tags, in the same syntax as the rest of the app, for example
site:madrid software_version:1.4.*. Click Syntax for a cheat sheet, or see Tags.
site:madrid tomorrow is covered automatically. Leave Where empty to watch every device that publishes the metric.
Scope: which devices to watch
Under Where, a live count shows how many devices match now, for example “27 devices match now”. Click show list to see them.- Device tags, such as
customerorsite, are judged on each device’s current tags. - Data tags, such as
cpu:cpu-total, are checked on each data point. The count names them (“1 condition checked on each data point”) but cannot count them.
Alert per
For Single Metric alarms, choose how incidents are raised:- Device: one incident per device, so amr-07 firing does not hide amr-11 firing. This is the default for new alarms. At most 100 devices per alarm fire at once; with a larger scope, narrow it or alert on the whole scope.
- Whole scope: one incident for the whole alarm, whichever devices cross the threshold.
Group comparison
Group Comparison alarms have a filter bar for Group A (test group) and Group B (control group), each with its own match count. Where applies to both groups, and each group adds its own tags, for examplesoftware_version:1.4.2 against software_version:1.4.1.
To explore a difference between two groups before turning it into an alarm, use the Compare panel.
Alarms saved with the older device metadata, site or tag filters keep working as before. When you open one, those filters are shown as Where conditions and are saved in the new form the next time you save the alarm.
Condition (when should it fire)
Set the condition that will trigger the alarm:- Evaluation Method: Choose whether the alarm looks at the latest single value or an aggregation (average, sum, min, max) across a time window.
- Evaluation Window: When using aggregated methods, set how long the system should look back (e.g., 5 minutes).
- Trigger Condition: Single Metric alarms support greater-than, less-than, exact equality, and inequality. Group Comparison also supports percentage comparisons.
- Threshold: The numeric value that will cause the alarm to trigger when the condition is met.
Log threshold alarms
Log threshold alarms reuse the monitoring query builder, so the source, topic, field, tag filters, and text filters behave like log queries on the Monitoring page. Text filters support contains, does not contain, and regular expression matching. Choose one compute mode:- Count matching logs: Counts entries for the selected log field.
- Unique attribute values: Counts distinct values of the selected field or a tag written as
tag:key. - Numeric measure: Aggregates a numeric field with average, sum, minimum, maximum, median, p75, p90, p95, p98, or p99.
Notifications (third-party channels)
You can route alarm events to connected third-party channels directly from the alarm form.- Channel selection: choose one or more connected channels (Slack, Telegram, or Microsoft Teams).
- Reuse destinations: channels are managed centrally in Settings and can be reused across multiple alarms.
- Resolve behavior: if a selected channel has notify-on-resolve enabled, it receives both firing and resolved messages.
Message
By default, notifications use a standard summary. Click Write a custom message to write your own with placeholders, shown in a preview next to the editor:
Click a placeholder to insert it. Use the default summary goes back to the standard message.
Settings
- Evaluate as soon as data arrives: When enabled, the alarm is checked within about a second of the data reaching the cloud, instead of waiting for the next scheduled check. Recommended for safety-critical conditions.
- Reaction Speed: Only shown when the above is enabled. The alarm is evaluated at most once per window however many devices are reporting, so a faster window reacts sooner and a slower one costs less on large fleets.
- Check Interval: How often the rule is evaluated (for example every 60 seconds). Shorter intervals give faster detection but may increase load. When “Evaluate as soon as data arrives” is on this becomes the Heartbeat Interval: a backstop check that still runs when no data arrives at all. It is what detects a missing-data condition and what resolves an incident after a device goes quiet, so it stays in effect either way.
- Enable toggle: Decide whether the alarm should be active immediately after saving.
Save and cancel
Use the Save button to create the alarm. If a required field is missing the app will highlight it and prompt you to complete the form. Use Cancel to close the form without saving changes.Practical tips
- Name alarms clearly and include a description with recommended next steps (who to contact, where to check, etc.).
- Start with conservative thresholds and test a rule in a limited scope before enabling it fleet-wide.
- Use Where to reduce noise and focus on meaningful groups of devices, and check the match count before saving.