Small-business fleets rarely justify a full observability stack, but they still need someone to notice when a laptop’s disk is full, a workstation has not patched in two months, or Defender has been switched off. Every RMM platform (NinjaOne, Datto, N-able, Action1, Atera and the rest) lets you build monitors from built-in checks and custom scripts; the hard part is deciding what to watch and at what threshold. This guide sets out a baseline that works for Windows 10/11 endpoints and small Windows Server 2019/2022/2025 estates, and that generates tickets people act on rather than alerts people ignore.
Table of Contents
Short answer: Monitor three things on every endpoint: free disk space on the system volume (warn at 15% or 20 GB, critical at 10% or 10 GB), patch age (alert when the last successful cumulative update is older than 35 days or a required reboot has been pending for 7 days), and antivirus health (Defender real-time protection on, signatures under 3 days old, no unresolved detections). Run each check hourly for disk and daily for the others, auto-remediate the simple cases, and raise a ticket only after the condition has persisted through two consecutive checks.
Disk space
Disk-full is the single most common cause of “my computer is slow” and of failed updates. Monitor the C: volume with a percentage and an absolute floor, because 10% of a 2 TB drive is very different from 10% of a 128 GB SSD. A script-based check gives both:
$vol = Get-Volume -DriveLetter C
$freeGB = [math]::Round($vol.SizeRemaining / 1GB, 1)
$freePct = [math]::Round(($vol.SizeRemaining / $vol.Size) * 100, 1)
if ($freeGB -lt 10 -or $freePct -lt 10) { Write-Output "CRITICAL $freeGB GB ($freePct%)"; exit 2 }
if ($freeGB -lt 20 -or $freePct -lt 15) { Write-Output "WARNING $freeGB GB ($freePct%)"; exit 1 }
Write-Output "OK $freeGB GB ($freePct%)"; exit 0
Attach an automatic remediation for the warning state: clear the Windows Update download cache, run cleanmgr /sagerun, empty recycle bins and remove the C:\$WINDOWS.~BT folder if older than 14 days. Escalate to a ticket only if the critical threshold holds after remediation.
Patch state
Most RMM tools have a native patch module, but the monitor should verify results rather than trust the schedule. Two checks: the age of the newest installed cumulative update and whether a reboot has been pending too long.
$last = (Get-HotFix | Where-Object Description -eq "Security Update" | Sort-Object InstalledOn -Descending | Select-Object -First 1).InstalledOn
$age = (Get-Date) - $last
$reboot = Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"
if ($age.Days -gt 35) { Write-Output "Patch age $($age.Days) days"; exit 2 }
if ($reboot) { Write-Output "Reboot pending"; exit 1 }
Write-Output "OK last patch $($last.ToShortDateString())"; exit 0
Thirty-five days allows one missed cycle before alerting, which suits offices where laptops travel. Pair the reboot-pending warning with a user notification and a forced restart outside working hours after seven days. For the current month’s package details see Windows 11 Patch Tuesday September 2026 (KB5124008).
Antivirus health
For Defender-based estates the Get-MpComputerStatus cmdlet exposes everything the monitor needs:
$s = Get-MpComputerStatus
$sigAge = (Get-Date) - $s.AntivirusSignatureLastUpdated
$issues = @()
if (-not $s.RealTimeProtectionEnabled) { $issues += "RTP off" }
if (-not $s.AntivirusEnabled) { $issues += "AV disabled" }
if ($sigAge.Days -gt 3) { $issues += "Signatures $($sigAge.Days)d old" }
if ((Get-MpThreatDetection | Where-Object ActionSuccess -eq $false).Count -gt 0) { $issues += "Unresolved detection" }
if ($issues) { Write-Output ($issues -join "; "); exit 2 }
Write-Output "OK"; exit 0
Third-party antivirus products register with Windows Security Center; query root\SecurityCenter2 with Get-CimInstance AntiVirusProduct and decode the productState value for enabled and up-to-date bits when Defender is not the primary engine. Auto-remediate stale signatures with Update-MpSignature; never auto-remediate a detection, that one always becomes a ticket.
Reduce the noise
- Require two consecutive failures before alerting; transient conditions during updates or backups otherwise flood the queue.
- Use maintenance windows tied to the patch schedule so reboot-pending alerts do not fire during the window you planned.
- Group alerts by client and severity in the ticketing integration, one ticket per device per condition, updated rather than duplicated.
- Review thresholds quarterly against the actual ticket volume; if a monitor generates tickets nobody actions, change it or delete it.
Verify the policy works
Deliberately break one condition on a test device: fill the disk with fsutil file createnew C:\bigfile.tmp 50000000000, or disable real-time protection briefly. Confirm the alert arrives at the expected severity, the remediation runs, and the ticket closes when the condition clears. Then delete the test file and re-enable protection.
Common pitfall
Monitors that run as SYSTEM see a different environment from the logged-on user. Disk checks are fine, but scripts that rely on user profile paths or mapped drives fail silently and report OK. Test each script from the RMM agent context, not from an admin console, before trusting its results across a client base.
RMM monitoring policy at a glance

Official documentation: Windows Server documentation.
Related guides: Check domain controller health with dcdiag and repadmin (what each test means) · Reset the Default Domain Policy and Default Domain Controllers Policy with dcgpofix · Install and promote a Windows Server 2025 domain controller step by step.
Frequently asked questions
Does this monitoring policy also apply to servers?
The three checks are the same, but tighten the thresholds: patch age of 40 days with a scheduled reboot window, disk warnings on every data volume rather than only C:, and antivirus exclusions verified against the server role. Add service and backup-job monitors for servers.
How long should an endpoint be offline before the RMM alerts?
For laptops, seven days is a sensible threshold; for desktops and servers, 24 hours. Shorter windows create noise from holidays and remote work, and an offline endpoint is not an incident until it fails to check in for longer than its normal usage pattern.
Can I roll back a monitoring policy that generates too many tickets?
Yes. RMM policies are versioned or at least editable; raise the thresholds or increase the consecutive-failure count, and clear the open alerts. No change is made on endpoints by the monitors themselves, so nothing needs reverting on devices.