Introduction
Monitor anything you can write a script for. Script monitors run a script on target devices on a set schedule and evaluate the output against a condition you define — if the condition is met, Level raises an alert.
Where the built-in monitor types cover common conditions (CPU, memory, disk, connectivity), script monitors cover everything else: firewall state, certificate expiry, license compliance, custom application health, configuration drift, and any other device characteristic you can surface with a script. The script runs locally on the device, so there's no external call overhead — just direct, efficient access to whatever the OS can report.
🎬 VIDEO
Script Monitors
Level runs the selected script on covered devices at your configured frequency. After each run, it reads the full console output and evaluates it against your Script output condition and Value. If the condition is met for the number of consecutive runs defined by your Trigger count, an alert fires.
The evaluation is simple by design: the script outputs something, the monitor checks whether that output matches your condition. The script doesn't need to exit with a specific code — the output is what matters.
ℹ️ NOTE: Level evaluates all output from the script, not just the first or last line. Keep this in mind when writing scripts that produce multi-line output.
Create the Script
Before configuring the monitor, write and save the script it will run. Any supported language works: PowerShell, Bash, Zsh, Python, Go, Ansible, or osquery.
💡 TIP: osquery runs on Windows, macOS, and Linux — a single osquery script can power monitors across all three platforms without maintaining separate scripts per OS.
The script should output a value or state that Level can evaluate cleanly — a number, a string like True/False, or a known word like Enabled. The monitor then compares that output to your threshold.
💡 TIP: For complex checks where multiple conditions need to be evaluated inside the script, output a known trigger word (like ALERT) when the condition is unhealthy, and set the monitor to Contains ALERT. This keeps the pass/fail logic inside the script while keeping the monitor configuration simple.
Configuring a Script Monitor
Open the target monitor policy, then add or edit a script monitor. The Edit monitor panel opens on the right.
Name and Type
Enter a name in the Name field. The name appears in the alert, so make it descriptive — "Windows Firewall Disabled" is immediately actionable; "Script Monitor 4" is not.
Set Type to Run script.
Severity
Set Severity based on the impact of the condition this script is detecting:
Information
Warning
Critical
Emergency
Operating System
Select the OS the script should run on: Windows, macOS, or Linux. The monitor will only execute on devices running the selected OS.
Script
Select the script to run from the Script field. Click the link icon to open the script and review or edit it. Click Test script to run the script against targeted devices immediately and inspect the raw output — useful for confirming the script returns what you expect before the monitor goes live.
Script Output
Script output defines how Level compares the script's console output to your Value. The full list of operators:
Equals — output matches the value exactly
Does not equal — output doesn't match the value
Contains — output includes the value as a substring
Does not contain — output doesn't include the value
Greater than — output (numeric) is greater than the value
Greater than or equals — output (numeric) is greater than or equal to the value
Less than — output (numeric) is less than the value
Less than or equals — output (numeric) is less than or equal to the value
ℹ️ NOTE: The full console output of your script becomes the alert payload. When an alert fires, the script's output is visible directly in the alert details — so anything you write to the console (device name, detected values, error details) will appear there. Writing useful context into your output makes alerts much easier to act on without having to dig further.
Value
Enter the value to compare the script output against in the Value field. For numeric operators, enter a number. For string operators, enter the exact string.
💡 TIP: The recommended pattern is to output ALERT (with any additional detail helpful for investigating) when a condition is unhealthy, and set Script output to Contains ALERT. This works cleanly with multi-line output, includes any detail you append after the keyword, and keeps the alert readable. Set the monitor to Does not contain ALERT if you want to invert the logic.
Run Frequency
Run frequency controls how often the script executes on target devices. Set the unit (Minutes or Hours) and the value using the slider or up/down arrows. Range is 1–120 minutes or 1–24 hours.
⚠️ WARNING: Running scripts at a very high frequency can affect device performance, particularly on lower-spec hardware or if the script itself is resource-intensive. Start with a longer interval and reduce it only if your use case genuinely requires faster detection.
Trigger Count
Trigger count sets how many consecutive script runs must match the condition before Level creates an alert. Use the up/down arrows to set the value.
A trigger count of 1 fires an alert on the first matching run. Higher values require the condition to persist across multiple runs before alerting — useful for conditions that might appear briefly due to timing (a script running mid-operation, for example).
Auto-Resolve
Auto-resolve alert if it is no longer applicable closes the alert automatically when a subsequent script run no longer matches the condition. Enabled by default.
Leave this on for conditions that genuinely clear (a value dropping back below a threshold, a string no longer appearing in output). Turn it off if you want alerts to persist for manual review.
Remediation
Attach one or more automations to run when this monitor fires — push a configuration fix, 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.
ℹ️ 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.
Saving the Monitor
Click Update monitor to save changes, or Add monitor when adding a new one. The monitor begins running immediately, with subsequent runs scheduled from the time of creation based on your configured frequency.
Examples and Inspiration
For end-to-end worked examples showing how to write a script and configure the monitor around it, see Script Monitor Examples.
The Level Library at level.io/library has a curated collection of ready-to-use scripts and monitor policies you can import into your account with one click. It's a good starting point whether you're looking to deploy something immediately or just want to see how others have approached a particular monitoring problem.
Best Practices
Use an ALERT sentinel as your standard output pattern. The recommended approach: write scripts to output ALERT (with any additional detail after it) when the device is in an unhealthy state, then set the monitor to Contains ALERT. This works reliably with multi-line output, is easy to scan in the alert list, and keeps the pass/fail logic inside the script where it belongs.
PowerShell Script
if ($condition) {
Write-Output "ALERT: $details"
exit 1
} else {
Write-Output "OK"
exit 0
}Keep evaluation logic in the monitor for simple checks. When a script produces a single clean value — a number, True/False, Enabled/Disabled — configure the comparison in the monitor rather than in the script. This makes the monitor easier to understand and adjust without touching the script.
Start with a longer run frequency. Reducing an interval is easy; dealing with performance impact from a script running too often is harder. High-frequency execution can affect lower-spec devices, especially if the script is doing meaningful work.
Use osquery for cross-platform coverage. osquery runs on Windows, macOS, and Linux and exposes device state through a SQL-like interface. A single osquery script can often replace three separate OS-specific scripts.
Test before deploying. Use Test script to run the script against a target device and inspect the raw output before the monitor goes live. This catches output format surprises — extra whitespace, unexpected line breaks, multi-line output — before they silently break your monitor.
FAQ
Who can create and edit script monitors? Technicians with access to the relevant monitor policy. Permission settings are managed in Workspace → Permissions.
How is a script monitor different from running a script via an automation? An automation runs a script in response to a trigger (a schedule, an alert, a manual action). A script monitor runs a script on a recurring schedule specifically to evaluate device health and raise an alert if a condition is met. Use monitors for ongoing health checks, automations for reactive or one-time tasks.
Can I use the same script in multiple monitors? Yes. A single script can be referenced by as many monitors as needed, across different policies. If you update the script, all monitors using it will pick up the change on their next run.
My script monitor isn't alerting even though I know the condition is true. What should I check? Use Test script to run the script against a target device and inspect the raw output. Common issues: the output has leading/trailing whitespace that breaks an exact Equals match, the output is multi-line and the matched value is getting lost, or the script is running against devices that don't match the expected OS.
What happens to open script monitor alerts if I delete the monitor? Existing alerts remain in place. Deleting a monitor doesn't close alerts it already created — resolve those manually.