Alarms – Hermetry

An alarm records that something is wrong with a device. It has a type (for example high_temperature), a severity, a status, a title, the device it belongs to, and a timeline of everything that happened to it. Alarms are opened by the alarm rules of a device profile, by a Rules-card rule, by a flow block, and closed by the same sources or by a person.

Severities

From highest to lowest. The UI shows the label; the API and alarm rules use the code.

Code	Label	Typical use
`CRITICAL`	Critical	Immediate danger or loss. Act now.
`MAJOR`	Major	Serious fault. Act soon.
`MINOR`	Minor	A fault with limited effect.
`WARNING`	Warning	Something is drifting toward a fault.
`INFO`	Info	Worth knowing; no action needed.

There are exactly five. Notifications treat CRITICAL specially: by default it reaches people even when they have turned that kind of notification off. See Alarm notifications in depth.

Statuses and lifecycle

Status	Label	Meaning
`OPEN`	Open	The condition is true and nobody has taken it yet.
`ACKNOWLEDGED`	Acknowledged	Someone has seen it and is on it. The condition may still be true.
`RESOLVED`	Resolved	Over. A resolved alarm never opens again; a new occurrence creates a new alarm.

(no alarm) --condition true--> OPEN
OPEN --someone acknowledges--> ACKNOWLEDGED
OPEN or ACKNOWLEDGED --condition clears--> RESOLVED (automatically)
OPEN or ACKNOWLEDGED --someone clears it--> RESOLVED (by hand)

Rules of the lifecycle:

One active alarm per device and type. If the condition fires again while the alarm is open or acknowledged, Hermetry counts an occurrence instead of creating a second alarm. The alarm page shows Fired n times.
Severity follows the highest true condition. It rises when a higher condition becomes true, and falls only when the higher condition has cleared. See Alarm rules on device profiles.
Escalation is heard again. A rise in severity is notified, even if the alarm was acknowledged. A fall is not.
Resolving by hand holds. If you clear an alarm while its condition is still true, the rule does not reopen it until the condition has been false at least once. The timeline shows Re-open held back after a manual clear once.
Alarms cannot be latched. There is no “must be acknowledged before it can clear” option. An alarm whose condition clears is resolved even if nobody acknowledged it. To review those, filter the Alarms page by Resolved and look for rows with no acknowledgement on their timeline.
Flapping. If an alarm opens and clears too often, its clear is held and it is marked Flapping. See Debounce, hysteresis and dampening.
Backfilled. An alarm opened from readings that arrived late (after an outage) carries a Backfilled badge and is dated by the readings. See Clear conditions and late readings.

What resolves an alarm

Cause	Recorded as
Its rule’s condition cleared (or its clear condition became true)	Cleared by the rule
A flow’s Clear alarm block, or a Rules-card Raise or clear an alarm action	Changed by a flow
A person clicked Clear	Cleared by hand, with the person and the optional note
Its alarm rule was removed from the profile and the rules were saved	Cleared, rule deleted
Its device was deleted	Resolved because the device is gone

Where alarms appear

Alarms in the IoT menu: the list of every alarm of your organisation. See Working with alarms.
The device page’s Alarms tab: the same list, for one device.
The bell in the top bar: the latest open alarms and a badge counting every open alarm. See The bell.
Dashboards: the Alarm table card and alarm counters. See Tables and lists.
Sites and site views, through the devices placed under them.
Notifications, webhooks and flows.

Permissions

Action	Permission	Default role
View alarms and alarm rules	View alarms and alarm rules	User
Acknowledge alarms and add notes	Acknowledge alarms and add notes	User
Clear alarms by hand	Resolve (clear) alarms by hand	Admin
Mute a device’s alarms	Mute the alarms of a device	Admin
Change alarm rules	Edit the alarm rules of device profiles	Admin

The permissions are in the IoT Alarms group. An administrator can grant them to other roles or groups. See Users and roles.

What is audited

Each acknowledgement and each clear by a person writes an audit entry (who, which alarm, its type and severity; never the note).
Clearing a CRITICAL alarm by hand writes an extra audit entry.
Every change to a profile’s alarm rules is one audit entry, and each changed rule gets a new version.
Mutes and the lifting of mutes are audited.

See Audit log.

History and retention

Resolved alarms, with their timelines and notes, are kept for 365 days by default and then deleted by a daily sweep. An administrator sets this in Alarms > gear icon (Alarm settings) > Keep resolved alarms (days). 0 keeps them forever. Open and acknowledged alarms are never deleted by retention.

Webhook events

Event	Sent when
`alarm.created`	An alarm opens.
`alarm.acknowledged`	Someone acknowledges it.
`alarm.cleared`	It is resolved, by its rule, a flow or a person.

A severity change sends no webhook event. See Webhooks.