Introduction
Alert when a device has been running continuously for longer than you want. The Uptime monitor watches how long a device has been up since its last restart, and fires once that count passes your threshold.
This is mostly about reboots that aren't happening. Pending patches that need a restart, slow memory leaks, drivers that misbehave after weeks of uptime. All of them tend to clear up with a reboot the machine never gets. The Uptime monitor surfaces those devices so you can do something about them.
How the Uptime Monitor Works
Level reads each covered device's uptime once a minute: the OS-reported time since the device last booted, floored to whole days. It's the same number you'd see in Task Manager's Uptime or from the uptime command, not a separate Level-side counter. When that day value reaches or passes your threshold, Level creates an alert.
There's no breach duration here. Unlike CPU or memory, uptime doesn't spike and recover, it only counts up until the device restarts. So the alert fires on the first check at or above the threshold, and resolves once the device reboots, uptime drops back to roughly 0 days, and the value falls below the threshold.
🖥️ PLATFORM NOTE:
Windows: Uptime resets on a true restart. With Fast Startup (hybrid shutdown) enabled, a normal Shut down followed by power-on may not reset the uptime Windows reports, because it resumes the kernel session from hibernation instead of doing a clean cold boot. If an uptime alert won't clear after a user "turns the machine off," this is usually why. A full Restart resets it.
macOS: Uptime resets on any restart or shutdown.
Linux: Uptime resets on any reboot or shutdown.
Configuring the Uptime Monitor
Open the monitor policy you want to add this to, then click + Add new monitor (or open an existing Uptime monitor to edit it). The Edit monitor panel opens on the right.
Name and Type
Enter a name in the Name field. Be specific. "Workstations - Uptime Exceeds 30 Days" reads better in an alert list than "Uptime Monitor."
Set Type to Uptime. The panel shows the description: "Alerts when a device has been running continuously for longer than the threshold."
Severity
Set Severity to match how your team should treat a device that's been up too long. Four levels are available:
Information: low priority, FYI-level
Warning: worth attention but not urgent
Critical: requires prompt response
Emergency: drop everything
💡 TIP: Information or Warning fits most uptime alerts. A device that hasn't rebooted in a month is a nudge, not a fire. Reserve Critical for cases where stale uptime has real consequences, like a security appliance that needs to pick up kernel patches.
Threshold
Threshold sets how many days a device can run continuously before the monitor fires. Adjust it with the up/down arrows or type a value directly. The field is measured in days, and the minimum is 1 day.
The monitor triggers when reported uptime is greater than or equal to the threshold. A threshold of 30 fires the moment a device's uptime reaches 30 days.
💡 TIP: 30 days is a sensible default for workstations: long enough that you're not nagging people over a normal work week, short enough to catch machines that never get rebooted. For servers with planned maintenance windows, set the threshold a few days past your reboot cadence so you only hear about the ones that slipped.
Auto-Resolve
Auto-resolve alert when conditions clear closes the alert automatically once the device reboots and its uptime drops back below the threshold. Turn this on unless you want alerts to persist for manual review.
ℹ️ NOTE: On Windows, "conditions clear" means a real restart. A Fast Startup shutdown won't reset uptime, so the alert won't auto-resolve until the device actually restarts. See the platform note above.
Remediation
Attach one or more automations to run when this monitor fires. For an uptime alert, the obvious move is to prompt the user to reboot, or schedule one.
Click in the Remediation field and select an automation. The screenshot example uses an Ask User To Reboot automation.
To add more, click + Add another remediation.
To remove one, click the × next to it. Click the eye icon to preview the automation, or the link icon to open it.
ℹ️ NOTE: Remediations run when the alert is created, not when it resolves.
Once attached, open the automation from its link to assign the monitor's payload to an automation variable if you want to pass alert context into the automation's logic. The uptime payload is a short string in the form Uptime: N days.
💡 TIP: Pair this monitor with a prompt-style automation rather than a forced restart. A device that's been up 45 days is often a workstation someone's actively using. Give them a window to save work. The Restart Action has built in options to Prompt Users for Approval for restarts.
Notifications
Under Notify recipients, two checkboxes control when emails go out. The helper text reads: "Sends emails to the policy's recipients when these events occur."
On alert creation: recipients get an email when the alert fires
On alert resolution: recipients get an email when the device reboots and the alert clears
Recipients are managed at the monitor policy level, in the policy's Recipients section, not on the individual monitor.
ℹ️ NOTE: If no recipients are set on the policy, no emails send regardless of these checkboxes.
FAQ
Why would I alert on high uptime? Isn't more uptime better? For servers, sustained uptime can look like a good thing, but it usually means pending OS and security patches haven't been applied, and most need a reboot to take effect. It can also mask slow memory leaks and driver issues that only clear on restart. The monitor isn't saying uptime is bad; it's flagging machines that have gone too long without the reboot their patch cycle assumes.
My uptime alert won't clear even though I shut the machine down. What's going on? On Windows, Fast Startup (hybrid shutdown) hibernates the kernel session instead of doing a clean cold boot, so a Shut down plus power-on doesn't reset the uptime counter. Do a full Restart instead, or disable Fast Startup on devices where this matters.
Does the threshold count from when I created the monitor, or from the device's actual boot time? From the device's actual last boot. Level reads OS uptime, so if a device has already been up 40 days when you create a 30-day monitor, it alerts on the next check (within about a minute).
How fast does it fire or clear? Level checks every minute, so an alert appears within about a minute of uptime crossing the threshold, and auto-resolves within about a minute of a reboot once OS uptime reads back below it.
What unit is the threshold in? Days, minimum 1. The reported value is floored to whole days, so a device at 29.9 days reads as 29.
Will this keep firing on a server that's been up for months? One alert stays open for the condition; it doesn't re-fire every day while uptime keeps climbing. With auto-resolve on, the alert closes when the device finally reboots.
Can I set different uptime thresholds for servers and workstations? Yes. Create separate monitor policies per tag and set the threshold independently on each.
Who can create and edit monitors? Technicians with access to the relevant monitor policy. Permission settings are managed in Workspace → Permissions.
What happens to open uptime alerts if I delete the monitor? Existing alerts stay in place. Deleting a monitor doesn't close alerts it already created, so resolve those manually.