Remote Monitoring: What to Monitor and Which Alert Thresholds to Start With

The short version: Monitor what stops people working or loses data: server and device availability, disk space, backup results, network links, critical services, patch and security status, and expiry dates. Alert only on conditions that need a human to act, require them to last a few minutes, and send each alert a clear owner. The thresholds below are starting points to tune after two to four weeks of baseline data, not standards.

This is for IT managers who are setting up a remote monitoring and management (RMM) tool, or checking what an outsourced provider monitors for them. You will get a list of what to watch, a starting warning and critical value for each, and the rules that keep alerts useful instead of noisy.

What remote monitoring means in practice

Remote monitoring and management (RMM) software puts a small agent on servers and devices, or polls them over the network, so a team can see their health and act without being on site. Monitoring collects the measurements and raises alerts. Management is what you do about them: run a script, restart a service, install a patch, open a ticket.

The tool matters less than the list of things it watches and what happens when an alert fires.

Build your monitoring in six steps

1. List what you must keep running. Servers, internet lines, firewalls, switches, key applications, backup jobs, cloud services. Rank them by what stops if they fail.
2. Collect the data. Install the agent on Windows devices and servers, and enable network polling (SNMP or the device's own interface) on switches, firewalls, access points, printers and UPS units. Check that every item on your list appears in the tool.
3. Run in observe-only mode for two to four weeks. Do not send alerts to people yet. Note normal levels, such as CPU on Monday mornings.
4. Set warning and critical thresholds from the baseline, starting from the lists below.
5. Route each alert to an owner, with a way to reach them out of hours for critical items. Create tickets automatically for warnings and page a person for critical ones.
6. Review monthly. For every alert that fired, ask: did someone need to act? If not, change or delete it.

Rules that keep alerts useful

1. Alert on sustained conditions. Require the condition to last, for example, 10 to 15 minutes, so a brief spike does not wake anyone.
2. Use three levels. Information (recorded, no action), warning (act within the working day), critical (act now). Link the levels to your priorities; see severity vs priority in IT incidents.
3. Every alert needs a next step. Write one line on what to check first. An alert nobody knows how to handle is noise.
4. Mute during maintenance. Schedule maintenance windows in the tool so planned restarts do not raise alerts.
5. Group related alerts. If a switch fails, you want one alert for the switch, not fifty for the devices behind it.
6. Watch the watcher. Monitor the monitoring: alert if an agent stops reporting or the tool cannot send mail or messages.

What to monitor and starting thresholds

All values here are starting points to tune for your environment. Time values mean "sustained for this long".

Servers and endpoints

1. Online status: critical if a server does not respond for 5 minutes. For laptops, warn if not seen for 14 days.
2. CPU: warning above 90% for 15 minutes; critical above 95% for 30 minutes.
3. Memory: warning above 90% used for 15 minutes; watch for steady growth over weeks, which suggests a leak.
4. Disk space: warning below 20% space left; critical below 10%. For large volumes add an absolute floor: warning below 50 GB, critical below 20 GB, whichever triggers first. Also watch how fast it is shrinking: a volume that will be full within 14 days deserves a warning even if it is above 20%.
5. Disk health: critical on any drive reported as not healthy, any RAID degradation, and any storage hardware fault.
6. Critical services: critical if an automatic service on the list is stopped (domain services, DNS, DHCP, database, line-of-business application, backup agent). Keep the list short and specific.
7. Event logs: warning on repeating critical or error events from the same source; alert on specific event IDs you have chosen for your applications.
8. Restart pending: warning if a restart has been pending for more than 7 days.
9. Security protection: critical if protection is off, or definitions are older than 3 days.
10. Patch status: warning if a device is missing updates past your deadline; see the patch management process.

Network

1. Device reachability: critical if a firewall, core switch or main access point does not answer for 3 to 5 minutes.
2. Internet line: warning when latency or packet loss is above your baseline for 15 minutes (a starting point is loss above 2%); critical when the line is down or the backup line has taken over.
3. Link utilisation: warning above 80% for 15 minutes; this is your signal to investigate before users complain.
4. Interface errors: warning on rising error or discard counters on a port.
5. Port flapping: warning if a port goes up and down several times in 10 minutes.
6. VPN tunnels: critical if a site-to-site tunnel is down for 5 minutes.
7. Wi-Fi: warning if an access point goes offline or client counts on one access point stay unusually high.
8. Configuration changes: information alert on changes to firewall or switch configuration, so unexpected changes are noticed.
9. Support and licence expiry: warning 60 days before, critical 14 days before.

Backup

1. Job result: critical on a failed job for a critical system; warning on a skipped or partially successful job.
2. Backup age: warning if the latest good backup is older than your recovery point target; see RTO vs RPO.
3. Storage: warning when backup storage is below 20% space left.
4. Restore test: record the date of the last successful restore test; warn if it is more than 90 days old.

Cloud and identity

1. Microsoft 365 service health: check Microsoft 365 admin center > Health > Service health, and use Customize > Email to get notifications about incidents for the services you use (checked against Microsoft Learn, 28 October 2026).
2. Sign-in risk: alert on repeated failed sign-ins, sign-ins from unexpected countries, and new administrator role assignments.
3. Licences: warning when you have fewer than 5% spare licences, or a licence is about to expire.
4. Mail flow: alert on a rise in undeliverable mail or a queue that grows.

Environment and expiry

1. UPS: critical when running on battery for more than 2 minutes or when battery health is flagged.
2. Room temperature: warning above the equipment maker's recommended limit; check the manual for your devices.
3. Certificates: warning 30 days before expiry, critical 7 days before.
4. Domain names: warning 60 days before renewal.
5. Website and key application checks: critical if the page or login does not respond for 5 minutes, checked from outside your network.

Sample check: services that should be running but are not

This command lists automatic services that are not running on a Windows server. Many are normal (for example, delayed-start services), so use it to build your list of critical services, not as an alert on its own. It uses Get-CimInstance, documented on Microsoft Learn (checked 28 October 2026).

Get-CimInstance -ClassName Win32_Service -Filter "StartMode='Auto' AND State<>'Running'" |
  Select-Object Name, DisplayName, State, StartMode |
  Sort-Object Name

Common mistakes

1. Alerting on everything. Hundreds of daily alerts train people to ignore them. Start with the critical items above and add more only when they prove useful.
2. No baseline. Thresholds copied from a list may be wrong for your busy times. Observe first.
3. Monitoring that nobody owns. An alert sent to a shared mailbox gets read by nobody. Name an owner and a backup.
4. Only watching devices, not services. A server can be up while the application on it is down. Add service and application checks.
5. Forgetting backup and expiry. Failed backups and expired certificates cause some of the most avoidable outages.
6. Never reviewing. Environments change. Review thresholds and the monitored list monthly.
7. Agent sprawl. Devices that join the network without an agent are invisible. Compare the tool's list with your inventory.

How to check it worked

1. Every item in your inventory appears in the monitoring tool, or is listed as intentionally excluded.
2. Switch off a test service or unplug a test device in a maintenance window and confirm the right alert reaches the right person within your target time.
3. Check that a critical alert reaches someone out of hours, and note how long acknowledgement takes. Track it with MTTA, MTTR and MTBF.
4. Count alerts per week and the share that led to action. If most did not, tune them.
5. Confirm the tool alerts when an agent goes quiet.

FAQ

What does remote monitoring mean?

It means watching the health of servers, devices and network equipment from a central tool, without being on site, and raising alerts when something goes wrong. Remote management adds the ability to act on the alert, such as running a script or restarting a service.

How much does remote monitoring cost?

It depends on how many devices and what types you monitor, what the tool covers (servers, endpoints, network, cloud), and whether people respond to alerts, or the alerts only arrive in a mailbox. We do not quote prices in articles; see our pricing page and ask for the scope each price covers.

How do I know if I have remote monitoring on my computer?

On a company computer, ask your IT team or provider, and check the list of installed apps for the management or monitoring agent they use. On a personal computer, any remote access tool you did not install yourself should be checked and removed, because attackers also use such tools.

What is the best software for remote computer monitoring?

We do not rank products. Compare them on what you need: Windows only or mixed devices, network device polling, alert rules and duration settings, ticket integration, scripting and patching, reporting, and how it behaves when an agent goes quiet.

What is the difference between remote monitoring and remote support?

Remote monitoring watches for problems and alerts you, usually before users notice. Remote support is a person connecting to a device to fix a problem, usually after someone reports it. They work best together.

Next step

If you would rather have monitoring and alert response handled for you, start with the Brocent operation center page.

Sources checked 28 October 2026: Microsoft Learn (Get-CimInstance). Thresholds and durations are starting points to tune.