Introduction
Alert when a device's CPU usage climbs above a threshold and stays there. The CPU Usage monitor fires once the condition has been sustained for your configured breach duration — so brief spikes don't create noise.
CPU Usage Monitor
Level samples CPU usage on covered devices. When usage exceeds your threshold and stays above it for the full breach duration, Level creates an alert.
The breach duration requirement is what separates a real problem from a momentary spike. A device pegging CPU for 30 seconds during an update isn't worth alerting on. A device sustaining 90%+ for 10 minutes probably is.
Configuring CPU Usage Monitor
Open the target monitor policy, then add or edit a CPU Usage monitor. The Edit monitor panel opens on the right.
Name and Type
Enter a name in the Name field. Something like "Workstations - High CPU" is more useful at a glance than "CPU Monitor."
Set Type to CPU usage.
Severity
Set Severity to match the urgency of a sustained CPU spike in this context:
Information
Warning
Critical
Emergency
💡 TIP: For workstations, Warning is usually appropriate — high CPU is common and often self-resolving. For servers running critical services, consider Critical.
Threshold
Threshold sets the CPU usage percentage that must be exceeded to trigger the monitor. Adjust using the slider or the up/down arrows. Range is 0–100%.
Breach Duration
Breach duration sets how long CPU must stay above the threshold before an alert is created. Adjust using the slider or up/down arrows. Range is 0–120 minutes.
💡 TIP: 5–10 minutes is a reasonable starting point for most environments. Too short and you'll get alerts from normal bursts (backups, updates, scans). Too long and you delay notification on a genuinely stuck process.
Auto-Resolve
Auto-resolve alert if it is no longer applicable (enabled by default) closes the alert automatically when CPU usage drops back below the threshold. Leave this on unless you want alerts to persist for manual review.
Remediation
Attach one or more automations to run automatically when this monitor fires — kill a runaway process, restart a service, or notify your team.
Click in the Remediation field and select an automation.
To add more, click + Add another remediation.
To remove one, click the × next to it.
Once attached, open the automation from the link icon to assign the monitor's payload to an automation variable if you want to pass alert context into the automation's logic.
ℹ️ NOTE: Remediations run when the alert is created, not when it resolves.
Notifications
Send notifications on alert creation — policy recipients get an email when the alert fires
Send notifications on alert resolution — policy recipients get an email when the alert resolves
Recipients are managed at the monitor policy level, in the Recipients section.
ℹ️ NOTE: If no recipients are added to the policy, notification emails won't send regardless of these toggle states.
Saving the Monitor
Click Update monitor to save changes, or Add monitor if adding a new one.
FAQ
Who can create and edit monitors? Technicians with access to the relevant monitor policy. Permission settings are managed in Workspace → Permissions.
Why is my CPU alert firing constantly on one device? The device may have a sustained load issue — a runaway process, misconfigured service, or resource contention. Use Background Management → Processes to inspect what's consuming CPU. You can also temporarily raise the threshold or breach duration for that device group while investigating.
What's the difference between threshold and breach duration? Threshold is the percentage that must be exceeded. Breach duration is how long it must stay exceeded. Both conditions must be met before an alert fires.
Can I set different CPU thresholds for servers vs. workstations? Yes — create separate monitor policies for each device group and configure different thresholds per policy.
What happens to open CPU alerts if I delete the monitor? Existing alerts remain in place. Deleting a monitor doesn't close alerts it already created — resolve those manually.