Alarm and Event History
Complete record of all past events with filters by period, source, and severity. Essential tool for root cause analysis and compliance.
Alarm and Event History
The History is the system's complete memory. All events that have arrived at Rela AI are recorded here — alarms, readings, processed and rejected events — with full information about what happened and what the agent did about it. It is the key tool for investigating a failure, responding to an audit, or understanding why a piece of equipment was down.
What is it for?
When a major failure occurs, the first questions are always: when did it exactly start? Were there prior signals? What did the maintenance team do? Was it escalated in time? Without an organized history, answering these questions takes hours and is often incomplete.
Rela AI's History stores every event with its exact timestamp, the agent's response, and who acknowledged or managed the alarm. This enables:
- Root Cause Analysis (RCA): see the exact sequence of events that preceded a failure
- Compliance audits: demonstrate that alarms were attended to within required timeframes
- Shift reviews: the outgoing supervisor can review all events from the shift
- Continuous improvement: identify sources with high event frequency to prioritize improvements
How does it work?
Every event that arrives at Rela AI is immediately recorded with:
- The exact timestamp of receipt
- The source of origin and the severity
- The event message and its metadata
- The processing status (whether it was processed, duplicated, filtered, etc.)
- The AI agent's response (complete analysis)
- The tools the agent executed
- The alarm status (whether it was acknowledged, by whom, and when)
Data is organized by month to maintain efficient access even with thousands of events.
How to use it?
Access the history
Go to Alarms > History in the sidebar.
Select the period
Use the period selector in year-month format to choose the month to query. It defaults to the current month.
Interpret the statistics panel
When you open the history, you will see a summary of the period:
- Total events: how many events arrived in the system that month
- By severity: breakdown in 4 categories (info, warning, critical, emergency) with their volume
- Top sources: the 10 origins with the most events — useful for identifying "noisy" sources (sources that generate many minor events)
Filter the event table
The main table allows filtering by:
- Source: see only events from a specific sensor or PLC
- Severity: focus on critical or emergency events
Table columns
| Column | What it shows |
|---|---|
| Timestamp | Exact event date and time |
| Source ID | Which sensor or PLC it came from |
| Event type | Event classification (e.g., HIGH_VIBRATION, TEMP_LIMIT) |
| Severity | Info, Warning, Critical, or Emergency with color |
| Alarm status | Whether it was acknowledged, shelved, or still pending |
| Processing status | How it was handled by the system |
| Message | Event description |
View the full detail of an event
Click any row to expand the full detail:
- Full message without truncation
- Event metadata (sensor values, additional data)
- Agent response: the complete analysis the agent generated
- Executed tools: what actions the agent took (if it created a task, sent a notification)
- Processing time: how long the system took to process the event
- Acknowledgment information: who acknowledged the alarm, when, and with what note
Acknowledge an alarm
If an event has unacknowledged status, you can acknowledge it directly from the history:
- Expand the event detail.
- Click Acknowledge.
- Add an optional note (e.g., "Technician assigned, being attended to").
- The event is marked as acknowledged with your name and timestamp.
Temporarily shelve an event
If an event is known and requires no immediate action (e.g., a recurring alarm already planned for next week):
- Expand the event detail.
- Click Shelve.
- Define how long (in minutes) it will remain shelved.
- Add an optional reason.
The event is temporarily silenced but remains in the history.
Processing statuses explained
| Status | Color | What it means |
|---|---|---|
| Accepted | Green | Event received correctly and awaiting processing |
| Processed | Green | The agent processed it and generated a response |
| Duplicate | Gray | Was identical to a recent event — ignored to prevent repetition |
| Throttled | Amber | Arrived too soon after the previous event from the same source |
| Filtered | Light gray | Did not meet the minimum severity configured for the source |
| Rejected | Red | The event was rejected (incorrect format, authentication failed) |
| Correlated | Blue | Linked with another existing event from the same origin |
| Flood Suppressed | Purple | The source was sending too many events — the system automatically suppressed them |
Key benefits
- Complete, immutable record of all system events
- Detailed analysis of each event: agent response, tools used, processing times
- Alarm acknowledgment with full traceability (who, when, with what note)
- Source and severity filters for specific investigations
- Monthly statistical summary to identify trends and problematic sources
- Full support for RCA and compliance audits
Common use cases
Scenario 1: Root cause analysis after a line shutdown On Monday at 6 AM, Line 2 stopped. The reliability engineer opens the history and filters events from the 12 previous hours for that line's sources. They see that at 2:14 AM there was a temperature warning on the main motor (WARNING, 78°C). At 4:31 AM another warning (82°C). At 5:47 AM a critical alarm (91°C, limit 90°C). At 5:48 AM the agent created a task — which no one acknowledged until 6:15 AM. Root cause: temperature rose gradually for 4 hours without intervention. Decision: review the night response protocol and change escalation to 15 minutes instead of 30.
Scenario 2: Compliance audit The safety auditor asks for evidence that all critical alarms in the quarter were attended to within the required 2 hours. The maintenance manager opens the history, filters by "critical" and "emergency" severity for the quarter's months, and exports the table with acknowledgment timestamps. The audit shows that 94% of critical alarms were acknowledged in under 45 minutes.
Scenario 3: Identify a "noisy" source The maintenance manager notices the team is receiving many notifications from sensor PT-05. They open the month's history and see in the statistics panel that PT-05 generated 847 events — 12 times more than any other source. Most are INFO severity. They decide to review the sensor's threshold and adjust the throttle to 300 seconds to reduce the noise.