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, and so on.
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 Type dropdown organizes monitors into six categories: Resources, Disk, Network, Security, System, and Custom. The monitor collections in these docs mirrors the same categories, so what you see in the dropdown maps directly to where you'll find the configuration article.
ℹ️ NOTE: Most monitor types work on Windows, macOS, and Linux. The two exceptions, Antivirus and Event log, are labeled Windows only directly in the dropdown.
Resources
Core compute metrics. Both use a threshold plus breach duration, so brief spikes don't fire alerts.
CPU usage — Fires when CPU exceeds a percentage threshold for a sustained duration. See CPU Usage Monitor.
Memory usage — Fires when RAM usage exceeds a percentage threshold for a sustained duration. See Memory Usage Monitor.
Disk
Capacity, performance, and hardware health. The four IO monitors (throughput, IOPS, latency, active time) plus queue length each measure a different dimension of disk activity, and together they explain most "this machine feels slow" tickets where CPU and memory look fine.
Disk usage — Fires when free space on any drive (or just the system drive) drops below a threshold. See Disk Usage Monitor.
Disk throughput — Fires when combined read and write rate (MB/s) stays above a threshold. Catches runaway backups and processes hammering the disk. See Disk Throughput Monitor.
Disk IOPS — Fires when read/write operations per second stay above a threshold. See Disk IOPS Monitor.
Disk latency — Fires when drives respond slowly for a sustained duration. Catches degrading disks before they fail outright. See Disk Latency Monitor.
Disk active time — Fires when the percentage of time drives spend busy servicing I/O stays above a threshold. See Disk Active Time Monitor.
Disk queue length — Fires when the number of pending disk operations stays above a threshold, meaning storage can't keep up with demand. See Disk Queue Length Monitor.
SMART status — Fires the moment any drive reports a failing SMART self-assessment. No thresholds to configure. See Disk SMART Status Monitor.
Network
Connectivity and bandwidth behavior.
Connection — Fires when a device goes offline (or comes back online) for longer than a configured duration. See Connection Monitor.
Network ping — Fires when ping latency from the device to a host you specify stays above a threshold. The ping originates from the device, not Level's infrastructure. See Network Ping Monitor.
Network saturation — Fires when bandwidth usage stays above a percentage of the device's link speed. See Network Saturation Monitor.
Network abnormal upload — Fires when upload bandwidth stays above a threshold. An early signal for exfiltration, misconfigured backups, or malware phoning home. See Network Abnormal Upload.
Security
Account and endpoint protection checks.
Encryption status — Fires when a device's primary partition isn't encrypted or encryption is in an unexpected state. Covers BitLocker, FileVault, and LUKS. Nothing to configure. See Disk Encryption Status.
Antivirus (Windows only) — Fires when Windows Security Center reports antivirus is disabled, out of date, or missing. Works with any AV product registered with Security Center. See Antivirus Monitor.
Failed login — Fires when failed login attempts meet your threshold within a time window. Native on Windows, macOS, and Linux, no event IDs or log parsing required. See Failed Login Monitor.
User — Fires when local accounts on a device differ from your known users list: an account you didn't authorize, or a required account that's gone missing. See User Monitor.
System
Software inventory, processes, services, logs, and reboot hygiene.
Application — Fires when an application is installed where it shouldn't be, or missing where it should be. See Application Monitor.
Process — Fires when a named process starts or stops running. See Process Monitor.
Service — Fires when a named service stops (or starts), with an option to restart it automatically. See Service Monitor. For Linux services, see Monitoring systemd Unit Files on Linux.
Event log (Windows only) — Fires when a specific Windows Event ID appears a set number of times within a defined time window. See Event Log Monitor.
Uptime — Fires when a device has run continuously past your threshold. Surfaces machines skipping the reboots that pending patches and leaky drivers need. See Uptime Monitor.
Custom
When none of the built-in types cover it, write a script.
Run script — Runs a PowerShell, Bash, or Python script on the device and evaluates the output against a condition you define. Software license checks, custom application health, registry values, anything you can script. See Run Script Monitor for configuration and supported output formats, and Script Monitor Examples for ready-to-adapt patterns.
ℹ️ 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.
Pick one disk IO monitor and tune it before adding more. The five disk performance monitors overlap in what they catch. Start with Disk latency or Disk active time, watch real alert volume for a week or two, and add others only if you're missing problems.
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.
Do all monitor types work on Windows, macOS, and Linux? Most do. The two exceptions are Antivirus and Event log, which are Windows only and labeled as such in the Type dropdown. Some cross-platform monitors have platform-specific behavior (Encryption status checks BitLocker, FileVault, or LUKS depending on OS), so check the individual monitor article if you're targeting a mixed environment.
There are five disk performance monitors. Which one do I actually need? They measure different dimensions of the same problem. Latency is how slowly the drive responds, IOPS is how many operations it's handling, throughput is how much data is moving, active time is how busy the drive is, and queue length is how far behind it's falling. For general "is this disk struggling" coverage, start with latency or active time. SMART status is different: it's a hardware failure predictor, and it belongs in nearly every policy.
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.