Alerts App
The Alerts App is your early warning system. It monitors equipment conditions in real time and notifies the right people the moment an asset enters a problematic state — whether that's a pressure threshold breach, a temperature spike, a low fuel level, or a diagnostic fault code. Catch issues before they become failures.
📊 The Dashboard
The Dashboard gives you immediate visibility into all active alert activity across your fleet.
Summary Charts
The top of the Dashboard contains four charts.
Alerts Priority Statistics — A donut chart showing the current count of Low, Medium, and High priority alerts across all your accessible assets. Hover over any segment to see the exact count.
Alerts Status Statistics — A donut chart showing how many alerts are currently Active, Acknowledged, or Snoozed. Use this to assess how well your team is keeping up with alert volume.
Alerts Priority Trend — A line chart showing how High, Medium, and Low priority alert counts have changed over the last 7 days. Hover over any point to see exact counts for a specific date. Use this to identify whether fleet conditions are improving or deteriorating.
Alerts Status Trend — A line chart showing Active, Acknowledged, and Cleared alert counts over the last 7 days. A rising Acknowledged count alongside a rising Active count may indicate your team is aware of issues but unable to resolve them — a signal worth investigating.
Active Alerts List
Below the charts, the Alerts List shows every active alert across all assets you have access to.
What does each column mean?
| Column | Description |
|---|---|
| Asset | The equipment generating the alert — click to navigate directly to that asset's detail page |
| Serial Number | Asset serial number |
| Priority | Color-coded badge — High (red), Medium (orange), Low (green) |
| Status | Current alert status — Active or Acknowledged |
| Event | The sensor or condition that triggered the alert |
| Type | Alert or Fault |
| Description | What condition occurred and why the alert fired |
| Created | When the alert was first triggered |
| Acknowledge / Clear | Action icons for managing the alert workflow |
| Add Comment | Log a note against the asset's timeline |
Available tools: Search by asset name, serial number, or status · Filter by priority · Request Data to export the current list to CSV.
Managing Active Alerts
Acknowledging an Alert
Click the 👍 thumbs up icon on an alert row to acknowledge it. This signals to your team that someone is aware of the condition and investigating — preventing duplicate response efforts.
Clearing an Alert
Click the ✕ clear icon on an acknowledged alert to close it once the issue has been resolved. The alert moves to Historical Alerts and is no longer visible on the active Dashboard.
⚠️ Clear alerts only after the underlying issue has been addressed. Clearing an alert does not resolve the equipment condition — it only removes it from the active view.
Adding a Comment
Click the comment icon on any alert row to attach a note to the asset's record. In the dialog, select the note type (Service Technician, Customer, or Distributor) and enter your note.
📌 Comments added from the Alerts Dashboard are permanently recorded in the asset's Timeline tab on the Asset Detail Page — creating a traceable link between the alert event and your response actions.
Navigating to the Asset
Click the asset name in any alert row to go directly to that asset's detail page. The ALERTS tab on the asset will show complete information about all current and historical alerts for that equipment.
📋 Alerts vs. Faults
The platform distinguishes between two types of alert conditions:
| Type | Description |
|---|---|
| Alert | A threshold-based condition triggered when a sensor value crosses a configured limit (e.g., temperature exceeds 200°F) |
| Fault | A diagnostic trouble code from the asset's onboard controller — automatically appears on the dashboard with medium priority, even without a specific alert configuration |
📌 When a fault is detected, it automatically appears on the dashboard — no separate alert configuration is required for fault codes.
🚦 Alert Priority Levels
Every alert is assigned a priority that determines both urgency and how the asset's map pin is displayed.
| Priority | Badge Color | Map Pin Color | Meaning |
|---|---|---|---|
| 🔴 High | Red | Red | Serious condition requiring immediate response — potential equipment damage or safety risk |
| 🟡 Medium | Orange | Yellow | Important issue to be addressed promptly during normal operations |
| 🟢 Low | Green | Green (unchanged) | Informational — monitor but no urgent action required |
💡 If an asset has multiple active alerts simultaneously, the map pin displays the highest priority color across all active conditions.
🔁 Alert Status Lifecycle
Every alert moves through a defined workflow from trigger to resolution.
| Status | Meaning | Typical Next Action |
|---|---|---|
| 🔴 Active | Alert has triggered — no action taken yet | Investigate and acknowledge |
| 👍 Acknowledged | A team member has noted the alert and is aware | Investigate and resolve, then clear |
| ✅ Cleared | Alert has been resolved and closed | Moves to Historical Alerts |
📌 Cleared alerts are removed from the active Dashboard and are only visible in the Historical Alerts page.
📁 Historical Alerts
Click Historical Alerts in the sidebar to review alerts that have been cleared or have returned to normal operating conditions.
Searching Historical Alerts
Historical Alerts requires search criteria before results are shown. Apply the following filters to retrieve records:
| Filter | Description |
|---|---|
| Date Range | Set a From and To date. Maximum range is 31 days. Data available up to 13 months back. |
| Status | Filter by Cleared or Returned to Normal |
| Priority | Filter by High, Medium, or Low |
| Asset | Narrow to a specific asset |
Click GO to retrieve matching records.
Historical Alerts Table
What does each column mean?
| Column | Description |
|---|---|
| Asset | Equipment that generated the alert |
| Serial Number | Asset serial number |
| Priority | Alert priority at time of trigger |
| Event | The condition that triggered the alert |
| Type | Alert or Fault |
| Status | Cleared or Returned to Normal |
| Created | When the alert originally fired |
| Cleared / Resolved | When it was closed |
Click any row to view the full alert chronology — when it became active, who was notified, when it was acknowledged, and when it was cleared or returned to normal.
⚙️ Alert Configurations
Alert Configurations are the rules that define what conditions trigger alerts, which assets they apply to, and who gets notified. Click Configuration in the sidebar to view and manage all configurations.
Configuration List
Each configuration in the list shows its name, the number of assets assigned to it, and the number of trigger conditions it contains.
Creating an Alert Configuration
Click ➕ on the Configuration list to create a new alert rule. Setup involves four steps.
Step 1 — Name and Notifications
What does each field mean?
| Field | Description |
|---|---|
| Configuration Name | A clear name describing what condition this configuration monitors (e.g., "High Discharge Pressure — Plant A") |
| Notification Contacts | Email addresses and platform users who receive notifications when the alert fires. Type @ to select platform users or enter any external email. SMS notification is also available. |
📌 Tip: If you include the word "fault" in the configuration name or the sensor name, the platform will classify resulting alerts as Faults — which are displayed and reported separately from standard threshold alerts.
Step 2 — Assign Assets
Select the assets this configuration applies to from the dropdown. When any assigned asset meets a trigger condition, it enters an alerting state and appears on the Dashboard.
⚠️ An alert configuration must have at least one asset assigned. The configuration will not activate without an associated asset.
Step 3 — Configure Triggers
Triggers define the specific conditions that cause alerts to fire. A single configuration can have multiple triggers, allowing one set of assets to be monitored for several different conditions simultaneously.
⚠️ Do not create multiple triggers for the same sensor within a single configuration. If you need additional trigger conditions for the same sensor, create a separate alert configuration.
For each trigger, configure the following:
What does each field mean?
| Field | Description |
|---|---|
| Sensor Group | The sensor group on the selected assets to monitor |
| Sensor | The specific data point to watch (e.g., DischargePressure, FuelLevel, CoolantTemp) |
| Condition | The comparison operator — equals, does not equal, less than, greater than, greater than or equal to, less than or equal to |
| Threshold Value | The value at which the condition triggers the alert |
| Priority | High, Medium, or Low — determines map pin color and notification urgency |
| Time Delay | How long the condition must persist before the alert fires (see Data Types section below) |
| Auto Clear | Whether the alert clears automatically when the condition returns to normal — choose Immediate or after a 24-hour delay |
| Notify on Return | Whether to send a notification when the asset returns to a normal state |
| Description | A plain-language explanation of what this trigger monitors and why |
Step 4 — Save
Submit the configuration. Alert rules are immediately active and begin monitoring all assigned assets.
Understanding Data Types and Time Delays
Alert behavior depends on whether the incoming sensor data is periodic or change-of-state. Setting the right time delay for each type prevents false alerts while ensuring genuine problems are caught quickly.
| Data Type | How It Works | Recommended Delay Approach |
|---|---|---|
| Periodic | Operational snapshots sent on a fixed schedule — typically every 15 minutes. Examples: run hours, RPM, coolant temperature, pressure readings. | Set a delay of at least 15 minutes so the system can receive and confirm the next scheduled reading before firing an alert. A momentary anomaly in one reading will not trigger a notification. |
| Change of State | Transmitted immediately when a status changes — engine on/off, switch positions, diagnostic fault codes. | Use a short delay (a few minutes) to prevent excessive notifications if the condition toggles rapidly around its threshold. |
💡 A well-calibrated time delay reduces alert fatigue — the condition where too many non-critical notifications cause teams to begin ignoring alerts. Longer delays reduce false positives; shorter delays provide faster awareness. Tune based on the criticality of the monitored condition.
Editing an Alert Configuration
Open any configuration from the Configuration list and click EDIT. All fields — name, notifications, assets, and triggers — can be updated. Changes take effect immediately after saving.
Deleting an Alert Configuration
Click the delete icon on the configuration's row in the Configuration list. Deleting a configuration removes all associated alert rules and notification subscriptions. Historical alert records for assets under this configuration are preserved.
🔄 Common Workflows
Workflow 1 — Daily Alert Review
- Open the Alerts Dashboard.
- Review the Priority Statistics chart — note any High priority alerts.
- Check the Priority Trend — is alert volume rising or falling over the past 7 days?
- Work through the Active Alerts list, starting with High priority items.
- Acknowledge each alert you are investigating.
- Navigate to the asset detail page for any alert requiring deeper inspection.
- Clear alerts once the underlying condition has been resolved.
✅ Result: Your team has a clear, shared understanding of which alerts are being handled and which still require attention — preventing duplicate effort and missed issues.
Workflow 2 — Investigating and Closing an Alert
- Identify the alert in the Dashboard list.
- Click the 👍 Acknowledge icon to signal you are investigating.
- Click the asset name to navigate to the Asset Detail Page.
- Open the ALERTS tab to review the full alert history for this asset.
- Investigate the condition using the SENSORS and TIMELINE tabs.
- Add a comment documenting your findings and actions taken.
- Return to the Dashboard and click ✕ Clear once the issue is resolved.
✅ Result: A complete audit trail from alert trigger through investigation to resolution, all linked to the asset's permanent record.
Workflow 3 — Setting Up a New Alert Configuration
- Create a new alert configuration:
- Name it to clearly describe the monitored condition.
- Add notification contacts (users and/or external emails).
- Assign the relevant assets.
- Add triggers:
- Select sensor group and sensor.
- Set condition type and threshold value.
- Set priority (High / Medium / Low).
- Configure time delay appropriate for the data type.
- Set auto-clear behavior.
- Save.
✅ Result: The platform begins monitoring all assigned assets against the configured conditions and sends immediate notifications when any threshold is crossed.
Workflow 4 — Reviewing Historical Alert Patterns
- Click Historical Alerts in the sidebar.
- Set a date range (up to 31 days at a time, up to 13 months back).
- Filter by a specific asset, priority, or status if needed.
- Click GO to retrieve records.
- Look for assets or conditions that appear frequently — repeated alerts on the same asset for the same condition may indicate a maintenance issue or a miscalibrated threshold.
- Export to CSV using Request Data for trend analysis or management reporting.
✅ Result: Pattern analysis across historical data identifies root causes rather than repeatedly responding to symptoms.
✅ Best Practices
-
🔔 Check the Dashboard at the start of every shift. Alerts waiting unacknowledged accumulate quickly on active fleets. Regular review prevents High priority items from aging unnoticed.
-
👍 Acknowledge before investigating. Acknowledging an alert as soon as you begin looking into it signals to the rest of your team that it is being handled — preventing two people from independently investigating the same issue.
-
📝 Use comments to document your response. Notes added from the Alert Dashboard are recorded permanently in the asset's Timeline. Future team members — and future you — will benefit from knowing what was done and why.
-
⏱️ Set time delays thoughtfully. A delay that is too short generates false alerts from momentary fluctuations. A delay that is too long may let a genuine problem go unnoticed. Match the delay to the data transmission interval and the criticality of the condition.
-
🎯 Reserve High priority for genuine emergencies. If too many conditions are flagged High, teams begin to treat all alerts with the same level of urgency — which is none. High priority should mean "respond now, regardless of time."
-
📊 Export and review monthly. Regular exports of alert data allow you to identify recurring conditions, track fleet health trends over time, and make a data-driven case for maintenance investment or equipment replacement.
💡 Tips & Shortcuts
| Tip | How |
|---|---|
| Jump to the asset from an alert | Click the asset name in any alert row to go directly to the Asset Detail Page |
| Export active alerts | Click Request Data on the Dashboard to download the current alert list to CSV |
| Search for a specific alert | Use the search field on the Dashboard to filter by asset name, serial number, or status |
| View full historical detail | Click any row in Historical Alerts to see the complete alert chronology |
| Keep the Dashboard clean | Clear alerts promptly once resolved — a cluttered Dashboard makes it harder to spot new issues |
📖 Alert Configuration Examples
Alerts depend on the type of data you receive:
- Periodic data — operational snapshots sent on schedule (typically every 15 min). Examples: Engine Run Hours, RPM, Coolant Temp.
- Change-of-state data — status changes transmitted immediately. Examples: engine on/off, low fuel switch, J1939 faults.
The delay workflow prevents excessive notifications from toggling conditions.
Example 1: Low-Fuel Alert (Periodic Data)
- Config: If Fuel Level ≤ 20% for 0 minutes → high priority, auto-clear after 24h.
- Fuel level reports 19% — below threshold. Alert appears immediately with zero-minute delay.
Example 2: Low-Temperature Alert (Periodic Data)
- Config: If Fluid Temp < 10°C for 20 minutes → medium priority, auto-clear after 24h.
- 9°C reported. Next value in ~15 min. If next report shows above 10°C → no alert. If still 8°C → alert fires at 20 min mark.
Example 3: High-Pressure Alert (Change-of-State)
- Config: If High Pressure Alarm = active for 5 minutes → high priority, auto-clear after 24h.
- 5-minute delay prevents notification floods from toggling. If inactive arrives during delay → cancelled. If still active → alert fires.