Alarms and Alarm Management
Alarms are the primary mechanism for alerting operators to conditions that require attention in a Mango system. An alarm is an event that has been assigned a severity level, making it visible in the alarm header, the events page, and to any configured event handlers. Understanding how alarms work -- from their severity levels through acknowledgment and filtering -- is essential for effective system monitoring and incident response.
Events, Alarms, and Handlers
Three core concepts work together in Mango's event system:
- Event: The occurrence of a defined condition within the system. Events can be system-defined (data source errors, user logins, startup/shutdown) or user-defined (point event detectors, module-specific events). Audit events are a special category raised when users modify runtime-affecting objects such as data sources, data points, event detectors, and event handlers.
- Alarm: An event that has been assigned an alarm level other than "None". Alarms appear in the header bar and require acknowledgment.
- Event Handler: A user-defined automated response that executes when an event is raised, such as sending an email, setting a point value, running a process, or executing a script. See Event Handlers for details.
Alarm Levels
Every event detector and system event has an alarm level that determines its visibility and severity. When unacknowledged alarms exist, a flag icon with an associated description or count appears in the header bar. The flag color indicates the highest severity level among unacknowledged alarms.
Standard Alarm Levels
The following alarm levels are listed from lowest to highest severity:
| Level | Color | Description |
|---|---|---|
| None | Gray | The event is logged and handled but does not produce a visible alarm in the header. Useful for events that should trigger handlers (e.g., send an email) but do not require operator acknowledgment. |
| Information | Cyan/Light Blue | Informational events that may be useful to review but do not indicate a problem. Examples: configuration changes, scheduled task completions. |
| Important | Green | Events of moderate significance that should be reviewed. Examples: first-time device connections, configuration milestones. |
| Warning | Yellow | Conditions that may indicate a developing problem. Examples: a sensor value approaching a limit, intermittent communication errors. |
| Urgent | Orange | Conditions that require prompt attention. Examples: a high-temperature alarm, a communication failure that has persisted beyond a threshold. |
| Critical | Red | Severe conditions that demand immediate action. Examples: equipment failure, safety interlock activation. |
| Life Safety | Dark Red/Magenta | The most severe level, reserved for conditions that pose a direct risk to human safety. Examples: fire detection, toxic gas leak, emergency shutdown failure. |
Reduced Visibility Levels
Two additional levels reduce the visibility of an event instance below what "None" provides:
| Level | Behavior |
|---|---|
| Do Not Log | The event is still processed by event handlers but is not stored in the event database, not added to the user event cache, and not sent as a WebSocket notification. Use this when you want handler execution (e.g., automated point sets) without any user-visible trace. |
| Ignore | The event is completely suppressed. It is not logged, not handled, not cached, and not sent as a notification. Use this to completely disable an event detector's effect without deleting it. |
Alarm Level Behavior Summary
| Level | User Event Cache | Database | Handled | WebSocket Notification |
|---|---|---|---|---|
| None through Life Safety | Yes | Yes | Yes | Yes |
| Do Not Log | No | No | Yes | No |
| Ignore | No | No | No | No |
| Audit | No | No | Yes | Yes |
Audit events are a special type that are handled and sent via WebSocket but are not stored in the standard event database or cached per user. They track configuration changes for future reconstruction or reversion.
The Events Page
The Events page (accessible from the main menu, sometimes labeled "Alarms") displays a table of all events stored in the system. This is the primary interface for reviewing, filtering, and acknowledging alarms.
Table Columns
- Alarm Level Flag: The colored flag icon at the far left of each row. Click it to add notes to the event.
- Message: The event's descriptive message. Long messages are truncated with an ellipsis; click to expand.
- Status: Shows whether the alarm is Active, Returned to Normal (with the RTN timestamp), or N/A (for instantaneous events).
- Duration: The elapsed time from alarm start to return-to-normal. If the alarm is still active, this shows the elapsed time since it started.
- Acknowledge: An empty circle indicates an unacknowledged event; a filled checkmark indicates an acknowledged event.
Filtering Events
The events table supports filtering by:
- Event Type: Filter by data point events, data source events, system events, or module-specific event types.
- Alarm Level: Show only events at a specific severity level.
- Active Status: Filter by Active, Returned to Normal, or N/A (instantaneous).
- Acknowledged Status: Show only acknowledged or unacknowledged events.
- Date Range: When the date filter toggle is enabled, only events within the selected time range from the Date Bar are shown. By default, date filtering is off and all events are displayed regardless of timestamp.
Sorting
Click any column header to sort the table by that column. An arrow next to the header indicates the current sort column and direction (ascending or descending).
Acknowledging Alarms
Acknowledging an alarm signals that an operator has seen the event and is either taking action or has determined that no action is required. Acknowledgment does not resolve the alarm -- the underlying condition may still be active.
Acknowledging a Single Alarm
Click the empty circle icon in the Acknowledge column for the specific event. The icon changes to a filled checkmark, and the acknowledgment timestamp and user are recorded.
Acknowledging Multiple Alarms
Click the Acknowledge # Events button to acknowledge all events matching the current filter criteria. This is useful for bulk acknowledgment after a known incident has been addressed.
Alarm Header Indicator
Unacknowledged alarms display in the header bar via the Alarm Icon. Clicking the icon expands a menu showing:
- The total count of unacknowledged events.
- A breakdown by alarm level.
Clicking any alarm level in the menu opens the Events page with filters automatically set to show unacknowledged events at that level.
Alarm Lifecycle
A typical alarm follows this lifecycle:
- Raised: An event detector determines that a condition is met (e.g., a value exceeds a high limit). The event becomes active, and any associated event handlers execute.
- Active: The alarm remains active as long as the condition persists. The alarm icon appears in the header bar. Escalation handlers may trigger if the alarm is not resolved within a specified time.
- Acknowledged: An operator acknowledges the alarm. This changes the icon in the Acknowledge column but does not affect the alarm's active state.
- Return to Normal (RTN): The condition that caused the alarm is no longer met (e.g., the value drops below the high limit). The event is deactivated, the RTN timestamp is recorded, and any "inactive" event handlers execute.
Some events are instantaneous -- they have a timestamp for when they were raised but do not have an active duration or return-to-normal time. Examples include "Point Value Update" and "State Change Count" detectors.
Adding Notes to Events
You can add operator notes to any event by clicking the alarm level flag icon at the far left of the event row. Notes are stored with the event and are visible to other users who expand the event message. Events with notes display a notes icon next to the message text.
Notes are valuable for:
- Recording what action was taken in response to an alarm.
- Documenting the root cause of an issue for future reference.
- Communicating between operators during shift changes.
Configuring Alarm Levels
Alarm levels are configured in different places depending on the event type:
- Point event detectors: Set the alarm level on the event detector configuration within the data point editor. See Event Detectors for details.
- Data source events: Some data source error events have configurable alarm levels in the data source editor.
- System events: System-level event alarm levels (e.g., license check, system startup, user login) are configured on the System Settings page under System alarm levels.
- Audit events: Audit event alarm levels are configured on the System Settings page under Audit alarm levels.
Best Practices
- Reserve Life Safety and Critical levels for conditions that genuinely require immediate attention. Overusing high-severity levels leads to alarm fatigue.
- Use the "None" level for events that should trigger automated handlers (such as email notifications or point sets) without cluttering the alarm display.
- Acknowledge alarms promptly and add notes explaining the response. This creates an audit trail and helps the next operator understand the system state.
- Review alarm frequency periodically. If an event detector generates dozens of alarms per day, the threshold or detector configuration may need adjustment.
- Use mailing lists with alarm-level thresholds to automatically notify the right people without requiring individual email handlers for every event type.
Related Pages
- Setting Up Event Detectors — Configure detectors that monitor data point values and raise alarms
- Event Handlers — Define automated responses to alarm events
- Email Notification Setup — Configure email notifications for alarm escalation and resolution
- Advanced Alarms with Meta Data Points — Create complex multi-point alarm conditions using scripting
- Users and Permissions — Configure per-user alarm email notification levels