--- title: Alarms description: Alarms watch a Device Variable against a threshold, raise events when the condition is met, notify alarm groups, and keep a searchable history. source: https://documentation.controlcomtech.com/platform/alarms --- # Alarms An alarm watches one Device Variable against one threshold. When the reading crosses that threshold the alarm turns on, records an event, and notifies the people subscribed to its alarm group; when the reading returns to normal the alarm turns off and records the recovery. > **Workflow Stage: Analyze** ## Overview Alarms sit on top of data you have already Connected, Collected and Stored. Each alarm names a Device Variable, a comparison operator and a threshold value, so the readings arriving from the Edge Server are evaluated as they land rather than on a schedule. Three objects make up the system. An **alarm** is the rule: variable, operator, threshold, severity and notification routing. An **alarm event** is the record written each time the rule changes state, carrying the value that caused it and a timestamp. An **alarm group** collects related alarms and owns the notification channels, so who gets told about what is configured once per group instead of once per alarm. The platform splits this across two areas of the app. **Events → Alarms** and **Events → Historical** in the sidebar are the operational views, showing what is wrong now and what has gone wrong before. **Administration → Alarms** holds the configuration, with a tab strip for the alarm list and the alarm group list. You can also reach the configuration from **Settings → General** through the **Alarms & events** row. ## Active Alarms **Events → Alarms** lists every alarm that is currently on. Four cards across the top summarise the situation: **Active alarms** counts open alarms and splits them into Critical (the Critical and High severities) and Warning (Medium, Low and Info); **Acknowledgement** counts how many are still awaiting an acknowledgement; **Assignment** counts how many have nobody working on them; and **Events · 24h** counts the events raised in the last day, split into Resolved and Open. ![The Alarms page showing four summary cards above a table of active alarms](https://documentation.controlcomtech.com/images/alarms/01-active-alarms.png) *Active alarms, with the severity, handling and occurrence columns* Below the cards, each row shows the alarm name with a severity dot, the Asset and Location the monitored Variable belongs to, who is handling it, when it was triggered, its alarm group, and how many times it has fired this year and this month. Filter chips narrow the list by **Severity**, **Group** (including alarms with no group, listed as Unassigned) and **Asset**, and the search box matches alarm names and descriptions. Clicking a row opens the event page for the current occurrence, where the alarm can be assigned, acknowledged and annotated. The row menu adds **View Event**, **View Event History** for the alarm's full trail, and shortcuts that open the monitored Variable in [Data Explorer](https://documentation.controlcomtech.com/platform/explorer). When nothing is wrong the page shows an "All clear" state. ## Configuring an Alarm Open **Administration → Alarms**. The list shows every alarm configuration with its **Logic** (the variable, the operator and the threshold) and its group, and the filter row narrows it by status, severity, group, or archived scope. ![The alarm configuration list under Administration with the Alarms and Alarm Groups tabs](https://documentation.controlcomtech.com/images/alarms/02-alarm-configurations.png) *Alarm configurations, each showing its condition in the Logic column* Click **Alarm** to open the create dialog. Pick the Variable first: the picker lists devices and their variables, and choosing one seeds a sensible default condition along with a generated name and description. Everything after that refines the rule. ![The Create Alarm dialog with a variable, operator, threshold, name and description filled in](https://documentation.controlcomtech.com/images/alarms/03-create-alarm.png) *Creating an alarm on a generator output voltage reading* | Field | Notes | | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Variable | The Device Variable to watch. Fixed once the alarm exists, so a different point means a different alarm. | | Operator | `LESS_THAN`, `LESS_THAN_OR_EQUAL`, `GREATER_THAN`, `GREATER_THAN_OR_EQUAL`, `EQUAL` or `NOT_EQUAL`. Boolean variables offer only `EQUAL` and `NOT_EQUAL`. | | Threshold Value | The number the reading is compared against, up to 999999. Boolean variables get a **Threshold Boolean** picker with True and False instead. | | Name | Required, up to 100 characters, unique within the Organization. | | Description | Optional, 5 to 100 characters. Shown on the alarm's detail page. | | Enable Logs | On by default. While it is off the alarm stops evaluating: no events are recorded and no notifications are sent. The list shows it as Disabled. | | Enable Acknowledgement | Lets an operator acknowledge the event while it is active. Off by default. | | Enable for Edge Server | The ControlCom Edge Server checks the threshold locally and distributes the event to any Edge HMIs connected to it. | | Alarm Group | The group that carries the notification channels. Leave it as **No Alarm Group** and the alarm records events but never notifies anyone. | | Processing Delay | No delay, 30 seconds, 1 minute, 5 minutes or 15 minutes. | | Severity | Info, Low, Medium, High or Critical. Defaults to Medium and drives the severity dot, the filters and the summary cards. | | Process Past Events | Only offered when creating. Evaluates stored readings for this variable and writes the events they would have produced. | The name and description keep regenerating from the condition until you type in them, so a rule reads as something like "Generator EG-1 is greater than 600" unless you give it your own wording. If an alarm with the same condition already exists on the same variable the dialog says so and disables **Create**, which keeps two identical rules from notifying twice for the same reading. **Processing Delay** is how you handle readings that spike and settle. The alarm waits the chosen interval after the variable first crosses the threshold, then re-reads the current value. If it has returned to a non-triggering state nothing is sent, and the next crossing starts a fresh delay window. A sustained condition fires exactly one delay interval after the first crossing, no matter how many readings arrive in between. Existing alarms are edited from the row menu or by clicking the row, which opens **Alarm Settings** with the same fields. **Replay** re-evaluates the stored readings from the last 24 hours, 7 days or 30 days and previews the events it would create, marking which of them are new, so you can backfill an alarm you added after the fact. Replay is unavailable while the alarm is on. **Archive** hides an alarm from the list without deleting its history, and archived alarms can be restored from the archived scope. Selecting several rows exposes the same actions in bulk, plus **Assign to group**, and the **Import** button loads a set of alarms from a file. ## Alarm Groups An alarm group answers the question "who should hear about this". Open **Administration → Alarm Groups** and click **Alarm Group** to create one with a name, a description, an **Enable** switch, and one switch per channel: **SMS**, **Email** and **Push Notifications**. ![The alarm groups list showing status, alarm count and enabled notification channels](https://documentation.controlcomtech.com/images/alarms/04-alarm-groups.png) *Alarm groups, with the channels each one has enabled* The list shows each group's description, its status, how many alarms are assigned to it, and which channels are on. Opening a group gives two tabs. **Settings** edits the fields above. **Subscriptions** lists everyone in the Organization with an SMS, Email and Push toggle each, so subscriptions are managed per person and per channel. A channel the group itself has switched off is struck through in the header and cannot be subscribed to. Notification routing therefore takes three steps, and all three have to line up. The alarm has to belong to a group, the group has to have the channel enabled, and the user has to be subscribed to that channel. An alarm left on **No Alarm Group** still records its events and still appears on the Alarms page, but nothing is sent. Grouping alarms by response rather than by equipment tends to work best: a "Critical Power" group that pages the on-call engineer by SMS, and a "Mechanical Systems" group that only sends email, is easier to keep honest than one group per panel. ## Responding to an Alarm Clicking an active alarm opens the event page for that occurrence. The header names the alarm, its severity, the Asset, Location, Device and alarm group behind it, the reading that tripped it against the threshold it broke, when it fired, and whether it is still Active or has Cleared. ![The alarm event page with assignment, an Acknowledge action and the event notes panel](https://documentation.controlcomtech.com/images/alarms/05-alarm-event.png) *An active alarm event, assigned and awaiting acknowledgement* Assigning the event to a person is how the Alarms page stops showing it as unassigned, and it is the filter the rest of the team uses to see what is already covered. **Acknowledge** records who accepted the alarm and when, and appears only when the alarm has **Enable Acknowledgement** switched on and the event is still active. A cleared event cannot be acknowledged after the fact. The **Event notes** panel holds every note written against this alarm, not just this occurrence, so the next person to see it inherits the context. Type into **Add a note** and click **Add note**. Underneath the header, the correlation timeline charts the alarm's own Variable around the time it fired, and the **Topology** panel walks the Asset tree upstream, downstream or both so you can add neighbouring points to the same chart and see what moved together. Administrators also get an **Alarm configuration** card with **Edit alarm**, which opens the same settings without leaving the page. ## Alarm History **Events → Historical** is the searchable record of every event, on and off, for the whole Organization. It opens on the current year to date; the date range picker at the top changes that, and **Calendar view** shows occurrences per calendar day so you can click straight into a bad day. ![The Alarm History page with the breakdown panel above a filtered table of events](https://documentation.controlcomtech.com/images/alarms/06-alarm-history.png) *Alarm History, with occurrence trends and the top alarm groups and locations* The **Alarm Breakdown** panel above the table compares this week, this month and this year against the preceding period, and ranks the **Top Alarm Groups** and **Top Locations** for the selected range. Clicking a bar filters the table to that group or Location, which is the quickest way to get from "we had a bad month" to the equipment responsible. Filter chips cover **Type** (device variable alarms or manually raised events), **State** (Active or Inactive), **Severity**, **Asset**, **Asset Type**, **Location**, **Group** and **Assigned To**, and every filter is mirrored into the page URL so a filtered view can be copied to someone else. Each row shows the event, who handled it and whether it was acknowledged, the alarm group, the timestamp, and how often that alarm has fired this year and this month. Clicking a row opens the event page for it. Both the export button and the **Export All** menu produce CSV. The export button covers the rows currently on screen, while **Export All** fetches the full result set for the current filters from the server first, which is what compliance evidence usually needs. For a single alarm rather than the whole Organization, open it from an alarm row menu with **View Event History**: that page shows the alarm's current status, its occurrence counts, and a trail of every trigger and recovery with the reported value, how long the condition lasted, and the notifications that went out. ## Permissions Alarm access is split between the operational views and the configuration, so a shift operator can work alarms without being able to change the rules that raise them. | Permission | Grants | | ----------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | `Events.ReadActiveAlarms` | The Alarms page | | `Events.ReadAlarmHistoricalEvents` | Alarm History and the event pages, alongside `ReadActiveAlarms` | | `Events.AcknowledgeAlarmEvent` | Acknowledging an active event | | `Events.SubscribeToEventNotifications` | Managing notification subscriptions | | `Alarms.ReadAlarmConfigurations` | Administration → Alarms | | `Alarms.CreateAlarmConfiguration`, `UpdateAlarmConfiguration`, `DeleteAlarmConfiguration` | Creating, editing, replaying and archiving alarms | | `AlarmGroups.ReadAlarmGroups` | Administration → Alarm Groups | | `AlarmGroups.CreateAlarmGroup`, `UpdateAlarmGroup`, `DeleteAlarmGroup` | Creating, editing and archiving alarm groups | Alarms depend on the Connect and Collect stages having brought the Variable into the platform, and they feed the stages after them: an alarm condition can be plotted in the Analyze stage with [Data Explorer](https://documentation.controlcomtech.com/platform/explorer), surfaced in the Visualize stage on a [dashboard](https://documentation.controlcomtech.com/platform/dashboards/overview) or a [one-line diagram](https://documentation.controlcomtech.com/platform/diagrams-detail/overview), and exported from Alarm History as evidence in the Report stage.