Overview
Events are Mango by Radix IoT's alarm and notification system. Understanding the event lifecycle — how events are raised, escalated, acknowledged, and resolved — is essential for configuring reliable alarm management. This article covers the full lifecycle from detection through resolution.
What Is an Event?
An event is a record that something noteworthy happened. Events can be informational ("data source started"), warnings ("value approaching limit"), or critical alarms ("high temperature exceeded"). Every event has:
- Alarm level — Minor, Information, Important, Warning, Urgent, Critical, Safety, plus Do not log and Ignore
- Timestamp — when the event was raised
- Source — what generated the event (data point, system, scheduled event)
- Message — human-readable description
- State — active, acknowledged, or returned to normal
The Event Lifecycle
Stage 1: Detection
An event detector monitors a condition (high limit, state change, no update, etc.). When the condition becomes true, the detector raises an event. The event is now active.
Stage 2: Handler Execution
When an event is raised, all event handlers linked to that detector execute. Handlers can send emails, run scripts, set point values, or trigger processes. Handlers fire once when the event is raised.
Stage 3: Active State
The event remains active as long as the condition persists. An active event appears in the alarm list and contributes to alarm counts on dashboards and Platform Manager views.
Stage 4: Acknowledgment (Optional)
A user can acknowledge an active event to indicate they are aware of it and taking action. Acknowledgment changes the event state but does not resolve the event. The alarm condition is still present; acknowledgment is an operational workflow step.
Stage 5: Return to Normal (RTN)
When the detector's condition becomes false (e.g., temperature drops below the high limit), the event returns to normal. RTN handlers can fire at this point (e.g., "alarm cleared" email). The event is now resolved.
Note
Not every event reaches this stage. Some events are instantaneous — they are raised and logged but are never considered active and never return to normal, so there is nothing for an RTN handler to fire on. They can still be acknowledged. Treat the stages below as the path a sustained alarm takes, not a rule every event obeys.
Stage 6: Purge
Events are kept in the event history based on purge settings, then removed from the database.
Warning
Purging is based on the event’s active timestamp only — it does not check whether the event is still active. An alarm that has been active since before the purge cutoff is deleted from the event table and dropped from Mango’s in-memory active list. A long-running alarm can disappear from the alarm list without ever returning to normal. Set purge periods longer than the longest alarm you expect to leave standing.
Event States Diagram
| State | Meaning | Visible in Alarm List |
|---|---|---|
| Active | Condition is true; alarm is ongoing | Yes |
| Acknowledged | User marked as seen; condition still true | Yes (marked) |
| Returned to Normal | Condition resolved; alarm cleared | In history only |
Alarm Levels
Alarm levels determine the severity and how the event appears in the UI:
| Level | Typical Use | Color |
|---|---|---|
| Minor | Lowest severity; still logged and still raises handlers | Grey |
| Information | Status changes, data source starts/stops | Cyan |
| Important | Noteworthy but not urgent | Teal green |
| Warning | Approaching limits; needs attention | Green |
| Urgent | Requires prompt response | Yellow |
| Critical | Equipment failure, process shutdown | Orange |
| Safety | Immediate danger to personnel | Red |
| Do not log | Handlers still run, but nothing is written to the event table, the user event cache, or the websocket feed | Grey |
| Ignore | Nothing happens at all — not logged, not handled, not shown | Grey |
Note
Two naming traps. The lowest severity level is labeled Minor in the interface even though the underlying value is named NONE, and the highest is labeled Safety, not “Life Safety.” Mango’s own help page still writes the first one as “None” — the alarm level picker and the events table say Minor.
The colors are not the intuitive traffic-light order. Warning draws green, Urgent draws yellow, and Critical draws orange — red is reserved for Safety alone. Operators coming from other SCADA products routinely misread a Critical alarm as a warning because of this.
Do not log and Ignore are the real tools against alarm fatigue. Do not log still executes handlers — use it when you want the automated response without the alarm noise. Ignore suppresses the event entirely.
Set alarm levels on the event detector, not the event handler. The handler executes the response; the detector determines the severity.
Event Handler Timing
- On raise: Handler fires when the event becomes active
- On return to normal: Handler fires when the condition clears
- On acknowledgment: Handlers are notified when a user acknowledges the event. Note the email handler sends nothing on acknowledgment — it only cancels pending escalations, and only in the mode described below. Script handlers can act on acknowledgment.
- Escalation: An email handler can escalate after the event has been active for a set delay. Each escalation entry has an Escalation mode with three choices: No escalation; Until inactive (return to normal), which keeps escalating until the condition clears, so acknowledging does not stop it; and Until acknowledged or inactive (return to normal), which stops once an operator acknowledges. Pick deliberately — the difference decides whether acknowledgment silences the escalation chain.
Event Persistence Across Restarts
Whether active events survive a restart is configurable, and it is not the same answer for every kind of stop. Five separate settings live under Administration → System settings → Event persistence settings, one per scenario:
| Setting | Default |
|---|---|
| When Mango crashes | Re-raise events if the condition occurs again on the next update |
| When Mango exits cleanly | Restore existing state |
| When restarting Mango via UI or REST | Restore existing state |
| When stopping/starting data points via UI or REST | Restore existing state |
| When stopping/starting data sources via UI or REST | Restore existing state |
Each takes one of three values:
- Restore existing state — the detector's state is saved on shutdown and restored on startup. Active events stay active and are not re-raised, so handlers do not fire again.
- Re-raise events immediately — state is saved, but active events are deactivated like a return-to-normal and then re-raised on startup. Handlers fire again. This is the legacy behaviour.
- Re-raise events if the condition occurs again on the next update — the state is discarded. Active events are deactivated, the detector starts empty, and the alarm only comes back if its condition occurs again.
Warning
The default for a crash is the discarding option. After an unclean shutdown, alarms that were active are deactivated and the detectors start with no state — so the alarm list can come back empty and stay empty until each condition re-occurs on a new value. A slow-moving point that is already past its limit may not produce a new crossing for a long time. If you need alarms to survive a crash, change When Mango crashes to Restore existing state or Re-raise events immediately.
There is also an Enable override popup option, off by default. Turning it on prompts you to choose a persistence setting for that one operation when you stop a data point or data source from the UI.
Common Event Lifecycle Patterns
Simple Temperature Alarm
- High Limit detector triggers when temperature exceeds 180°F
- Email handler sends notification to maintenance team
- Operator acknowledges the event in the alarm list
- Maintenance addresses the issue; temperature drops below 180°F
- Event returns to normal; optional RTN email sent
Escalation Pattern
- Critical alarm raised
- Email sent to on-duty operator
- If not acknowledged within 15 minutes, escalation handler sends SMS/email to supervisor
- If still not acknowledged within 30 minutes, escalation to plant manager
This pattern only behaves as written if each escalation entry uses the Until acknowledged or inactive (return to normal) mode. Under Until inactive (return to normal), acknowledging the alarm does nothing to the chain and the plant manager is still paged at 30 minutes.
Best Practices
- Use appropriate alarm levels — not everything is Critical. Over-alarming causes alarm fatigue
- Configure RTN handlers — operators need to know when an alarm clears, not just when it fires
- Require acknowledgment for important alarms — creates an audit trail of operator response
- Use escalation handlers for safety-critical alarms that must not be missed
- Review active alarms regularly — stale, unacknowledged alarms indicate gaps in the alarm management process
- Always enable the date filter on the Events page — on large systems with thousands of historical events, loading the events list without a date filter can cause significant performance issues or browser timeouts
Tip
Mango supports a “read message aloud” feature for audio alerts. When configured, the browser will speak the event message text using text-to-speech when an alarm fires. Configure audio alerts per alarm level under Platform management → UI settings. This is useful for control room environments where operators may not be watching the screen continuously.
Warning
On systems with large event histories, always set a date range filter before opening the Events page. Loading unfiltered events on a system with hundreds of thousands of records can freeze the browser or cause server-side timeouts.
Summary
The Mango event lifecycle flows from detection to handler execution to active state, optional acknowledgment, and return to normal. Understanding this flow is essential for building reliable alarm systems. Configure alarm levels on detectors, handler timing based on operational workflow, and always consider the full lifecycle — including escalation and RTN — when designing your event strategy.