Introduction
Monitor policies define what Level watches on your devices and who gets notified when something goes wrong. Each policy bundles one or more monitors, a set of target tags, and a list of alert recipients — so you can apply a coherent set of checks to any group of devices just by tagging them.
This article covers how policies work, how to create and configure them, and which monitor types are available. For configuration details on specific monitor types, see the linked articles in each section below.
🎬 VIDEO
Monitoring Policies
A monitor policy has three parts:
Targets: One or more tags. Every device carrying a matching tag is observed by this policy.
Monitors: The individual checks — CPU usage, disk space, a service status, a script result, etc.
Recipients: Email addresses that receive notifications when monitors in this policy trigger alerts.
When a monitor's threshold is exceeded, Level opens an alert and (if configured) emails the recipients. If Auto-resolve is enabled on that monitor, the alert closes automatically once the condition clears. If it's off, a technician must manually resolve it from the Alerts view.
Tags are the mechanism that links policies to devices. Apply a tag to a device, and Level immediately checks whether any monitor policies target that tag — then applies those policies automatically. Remove the tag and those policies stop monitoring that device. The Monitors tab on a device's detail page shows every monitor currently active on it, across all policies and tags, in a single flat list. See Device Details → Monitors for more.
💡 TIP: Design policies around roles, not just device types. A policy called "Domain Controllers" that monitors AD-specific services pairs naturally with a tag of the same name — making it obvious which devices it covers and easy to assign.
Policies View
Navigate to Monitors in the sidebar. The Monitor policies page lists every policy in your organization.
Each row shows:
Name: The policy name, with a count of monitors and a link to the devices it currently targets
Created / Created by: When the policy was created and which technician created it
Last edited / Last edited by: When and by whom the policy was last modified
To customize which columns appear, click Columns in the top right. On the policies listing, you can toggle: Name, Created, Created by, Last edited, and Last edited by.
To delete one or more policies, check the box next to each row and click Delete.
Creating a monitor policy
Click + Create monitor policy in the top right.
Enter a name in the Monitor policy name field. The placeholder text suggests "e.g. Laptop policy" — pick something that reflects the role or device group this policy covers.
Click Create.
The new policy opens immediately. You'll land on the policy detail view, ready to add targets and monitors.
Configuring Targets
The Targets panel on the left side of a policy controls which devices it monitors. Targets are tag-based — add a tag here and every device carrying that tag gets monitored by this policy.
To add a target tag:
Click + in the Targets panel header.
Search for an existing tag or click Create new tag to create one on the spot.
Select the tag. It appears in the panel with a live count of the devices currently carrying it.
To remove a target tag:
Click the three-dot menu next to a tag in the Targets panel and select Remove target.
ℹ️ NOTE: Targets update dynamically. If you add a tag to a device after the policy is already configured, that device starts being monitored immediately — no changes to the policy required.
Configuring Recipients
The Recipients panel sits below Targets on the left side. Recipients receive email notifications when monitors in this policy trigger or resolve alerts.
To add recipients:
Click + in the Recipients panel header.
Enter one or more email addresses in the Email field. Hit Tab or add a comma to enter multiple addresses at once.
Click Add recipients.
To remove a recipient:
Click the three-dot menu next to a recipient's email and select Remove recipient.
ℹ️ NOTE: Recipients here receive notifications for all monitors in this policy. Whether a specific monitor actually sends notifications on alert and on resolution is controlled on each individual monitor — but the recipient list is shared across the whole policy.
Monitor Configuration
The right side of the policy shows all monitors attached to it. This is where you see what the policy is actually checking.
Default columns visible in the table:
Column | Description |
Name | The monitor's name |
Type | The monitor type (CPU usage, Disk usage, Event log, Run script, etc.) |
Threshold/Duration | The configured threshold value and the duration a condition must persist before triggering |
Severity | Information, Warning, Critical, or Emergency |
Three additional columns are available but hidden by default. Click Columns to enable them:
Remediation automations: Any automation set to run when the monitor triggers
Auto-resolve: Whether the alert closes automatically when the condition clears
Send notifications: Whether this monitor sends email notifications
Adding a Monitor
Click + Add new monitor in the top right of the policy view. This opens a monitor configuration panel where you choose the monitor type and set its parameters.
The available monitor types fall into two categories:
Built-in monitors
These watch standard system metrics without requiring any script:
CPU usage — Triggers when CPU exceeds a percentage threshold for a sustained duration. See CPU Usage Monitor.
Connection — Triggers when a device goes offline for longer than a configured number of minutes. See Connection Monitor.
Disk usage — Triggers when available disk space on any drive (or just the system drive) drops below a threshold. See Disk Usage Monitor.
Event log — Triggers when a specific Windows Event ID appears a set number of times within a defined time window. See Event Log Monitor.
Memory usage — Triggers when RAM usage exceeds a percentage threshold for a sustained duration. See Memory Usage Monitor.
Process — Triggers when a specific process starts or stops running. See Process Monitor.
Service — Triggers when a specific Windows service stops or starts. See Service Monitor.
Script monitors
Script monitors run a PowerShell, Bash, or Python script on the device and evaluate the output against a configured condition. Use these for anything the built-in types don't cover — software license checks, custom application health, registry values, and so on.
Run script — See Run Script Monitor for full configuration details and supported output formats.
For examples: Script Monitor Examples.
ℹ️ NOTE: A policy can contain multiple monitors of the same type. If you need separate thresholds for Warning and Critical disk levels, add two Disk usage monitors to the same policy with different thresholds and severities.
How Alerts Work
When a monitor's threshold is breached, Level opens an alert and captures a payload reflecting device state at the time of the trigger. What's in that payload depends on the monitor type:
CPU monitors show the top processes by CPU usage at the moment the alert triggered
Memory monitors show the top processes by memory consumption
Script monitors show the raw output the script returned
Event Log monitors show the matching event details: Event ID, source, and message
The payload stays live and synced for as long as the alert is open. Once the alert resolves, Level freezes it — preserving the last bad state at the moment of resolution. That frozen snapshot is what you see when you expand a resolved alert.
To view and triage alerts across all devices, go to the Alerts global view. To see alerts scoped to a single device, open the device and click the Alerts tab. See Alerts and Device Details → Alerts for details.
💡 TIP: If a monitor keeps re-triggering on one specific device but not others, open that device's Alerts tab and expand the payload. Level captures the exact values at trigger time, which is usually the fastest way to spot what's different about that device.
Policy-level actions
Click Actions in the top right of a policy to access:
Rename — Rename the policy
Delete — Permanently delete the policy
⚠️ WARNING: Deleting a policy removes all its monitors and stops monitoring on all targeted devices immediately. Alerts that were open at the time of deletion remain in the Alerts view but will no longer update or auto-resolve.
Resource Library
Level's Resource Library has hundreds of ready-to-use monitor policies and scripts built by the Level team and the community. Any of them can be imported directly into your account with one click — no configuration required to get started.
💡 TIP: Before building a monitor from scratch, check the Resource Library. There's a good chance a policy already exists for what you need — domain controller health, antivirus status, backup verification, uptime checks, and more.
Best Practices
A few patterns that hold up in practice:
Keep policies role-focused. Split resource monitoring (CPU, memory, disk) from application monitoring (services, processes). A domain controller policy should only monitor domain controller functions — not generic workstation metrics.
Match policy names to tag names. If your tag is "Exchange", name the policy "Exchange Monitoring". The pairing is obvious and makes auditing easier.
Disable auto-resolve selectively. Leave auto-resolve off only when you want a technician to investigate the root cause. If it's off everywhere, unresolved alerts pile up and create noise.
Don't overload a single policy. Level supports multiple policies per device via tag overlap. A device can receive checks from a "Workstations - Resources" policy and a "Huntress" policy simultaneously — use that.
Use per-device disable for permanent exceptions, not policy changes. If one device generates noise for a monitor that's valid everywhere else, disable that specific monitor on that device from Device Details → Monitors. Don't weaken the policy for everyone else. For temporary suppression during planned work, use Maintenance Mode instead.
FAQ
Who can create and edit monitor policies? Monitor policy management requires appropriate permissions for your organization. Technicians with restricted access may be able to view policies but not create or modify them. See Workspace → Permissions for details.
Can one device be monitored by more than one policy? Yes. If a device carries multiple tags and each tag is targeted by a different policy, that device receives all of them. Each policy runs its monitors independently. You can see the full list on the device's Monitors tab, including which tag pulled in each policy.
Why isn't a monitor triggering even though the threshold should be exceeded? Check that the device's tag appears in the policy's Targets panel with a non-zero device count. Also check the monitor's Duration setting — most monitors require a condition to persist for a defined period before firing. If the device is in Maintenance Mode, alerts are suppressed. If the monitor has been manually disabled on this device, it won't fire regardless of policy settings — check Device Details → Monitors.
Can I add a recipient who isn't a Level technician? Yes. Recipients are plain email addresses — they don't need a Level account. Any address you add will receive notifications for this policy's alerts.
What happens to open alerts if I remove a target tag from a policy? Existing open alerts from those devices remain visible in the Alerts view. New alerts won't be created since the devices are no longer targeted. Alerts won't auto-resolve unless the monitor's auto-resolve was already enabled.
An alert resolved and came back — why does it show the original start time? Level reopens an existing alert rather than creating a new one if the same monitor fires again within 24 hours. The original start timestamp is preserved. If the alert keeps cycling, the start time reflects when it first opened, not its most recent trigger. After 24 hours without re-triggering, Level creates a fresh alert with a new start time.