Introduction
See every alert that's fired on a device, dig into what triggered it, and track how it was resolved. The Alerts tab in device details scopes the global alerts view down to a single device — same data, tighter context.
Active Alerts
The Active tab lists every open alert for the device. Each row shows the alert's severity badge, what triggered it, when it started, and whether an automation ran in response.
Alert Table
Each alert row contains:
Severity — the alert level set on the monitor: Information, Warning, Critical, or Emergency
Trigger details — the monitor name and the condition that fired (e.g., "CPU usage >75.0% for 10 minutes")
Alert started — when the alert first opened
Automation ran — if a remediation automation was linked to the monitor, its name appears here; click it to view that automation run's details
💡 TIP: If an automation ran, open it from this column to see exactly what actions executed, what the output was, and whether remediation succeeded — without leaving the device context.
Alert Payload
Click the › chevron on any row to expand the alert payload. What you see depends on the monitor type:
CPU monitors show the top processes by CPU usage at the time the alert triggered
Memory monitors show the top processes by memory consumption
Script monitors show the raw output your script returned
Event Log monitors show the matching event details, including Event ID, source, and message
The payload is captured when the alert opens and stays static as long as the alert remains open. If you resolve the alert and it later reopens, the payload updates to reflect conditions at the time it reopened.
Searching and Filtering
Use the Search field to filter alerts by monitor name or trigger text. Click Filters to filter by severity. Click Columns to show or hide the Alert source column (hidden by default), which identifies which monitor policy the alert originated from.
Resolving Alerts
💡 TIP: If the monitor has Auto-resolve enabled, Level closes the alert automatically once the condition clears. You don't need to manually resolve it.
To resolve a single alert, open its row menu (the ⋮ icon) and select Resolve. To resolve multiple alerts at once, check the boxes next to the rows you want, then click Resolve in the toolbar.
ℹ️ NOTE: Resolving an alert marks it as closed. If the same monitor condition is detected again within 24 hours, Level reopens the existing alert rather than creating a new one — and keeps the original start timestamp. You'll likely see the alert come back to the Active tab instead of appearing under Resolved. After 24 hours without re-triggering, Level creates a fresh alert.
Resolved Alerts
The Resolved tab shows every alert that's been closed, whether by a technician, an automation, or auto-resolve. Alerts are stored indefinitely — there's no expiration.
The resolved table adds two columns not present on the Active tab:
Alert resolved — when the alert was closed
Resolved by — who or what closed it: a technician's name, "Auto-resolved" if the monitor's auto-resolve fired, or blank if resolved via automation
The resolved tab also supports search, making it practical for reviewing a specific monitor's history. Expand any resolved alert row to see its payload, just like on the Active tab.
💡 TIP: Use the resolved tab to audit recurring issues. If the same monitor is firing and resolving repeatedly, that's a signal to investigate the root cause or adjust the monitor threshold.
FAQ
Why did an alert disappear from Active but I can't find it under Resolved? Level reopens an existing alert if the same monitor fires again within 24 hours. When it reopens, it goes back to Active — and it keeps the original start time, so the timestamps can look confusing. Check the Active tab and look for an older start date on a current alert.
Who can resolve alerts on a device? Any technician with access to the device's group can resolve alerts. Permissions are configured at the group level. See Workspace → Permissions for details on how access is scoped.
What does the Automation ran column show if no automation was linked to the monitor? It shows
--. An automation only appears there if the monitor that triggered the alert had a remediation automation configured.The alert payload is blank — why? Some monitor types don't generate a payload. Connection monitors (offline alerts) and process/service monitors may show no payload beyond the trigger condition itself. Script monitors only populate a payload if your script outputs text to stdout.
Why does an alert show a start time from months ago but still appears in Active? The original start timestamp is preserved every time an alert reopens. If a monitor has been cycling — firing, auto-resolving, and firing again — the start time reflects when the alert first opened, not its most recent trigger.