What Your IT Support Provider Should Be Monitoring (And Probably Isn't)

Most managed IT contracts include "remote monitoring and management" as a feature. The RMM agent is installed on your devices, and your provider can see what's going on. In theory.

In practice, whether that monitoring is actually useful depends on what thresholds are configured, whether alerts are acted on proactively, and whether anyone is looking at the data. I've reviewed a lot of monitoring setups and found significant variation in what's actually happening.

Server and Infrastructure Monitoring

At minimum, your provider should be monitoring:

Disk space — alerts when volumes are approaching capacity, well before they fill. A server running out of disk space causes varied and unpleasant problems. This should never be a surprise.

CPU and memory — sustained high utilisation over days or weeks indicates either a performance problem or a growing workload that needs addressing. Spikes are normal; persistent elevation isn't.

Service health — critical services (email, databases, active directory) should be monitored for availability. If your email server's service stops, you want to know within minutes.

Backup success/failure — every backup job should be monitored for completion. A backup that silently fails for three months before you need to restore from it is a business-continuity failure. Your provider should be able to tell you, unprompted, when your backups last succeeded.

Event log monitoring — Windows event logs contain a lot of noise, but also meaningful signals — repeated authentication failures, application crashes, storage errors. Alerting on high-priority events is straightforward with any modern RMM tool.

Security Monitoring

This is where the gap between basic monitoring contracts and genuine security coverage is widest.

Basic monitoring tells you when something has already gone wrong. Security monitoring is looking for signs that something is about to go wrong — unusual login patterns, suspicious processes, unexpected outbound connections.

If your provider includes endpoint detection and response (EDR) rather than traditional antivirus, ask how alerts from the EDR tool are handled. Are they reviewed by a human? On what timescale? Many EDR products generate alerts that get acknowledged and closed without being properly investigated.

Ask your provider: in the last six months, have there been any security alerts from our environment? What were they? How were they resolved? If they can't answer, monitoring may be happening but not being acted upon.

What Gets Missed

Patch compliance reporting is often less rigorous than it should be. Ask your provider what percentage of your devices are fully patched against critical vulnerabilities. Not "we have patching enabled" — actual compliance figures.

Third-party application patching is separate from Windows updates and often handled poorly. Browsers, Adobe products, and common business software are frequent attack vectors. Many monitoring setups cover Windows updates well and ignore everything else.

User-reported problems that don't open a ticket don't get tracked. If staff are working around IT problems — rebooting a specific PC every morning, avoiding certain features of the accounting software — this context gets lost unless there's a mechanism for capturing it.

What to Ask Your Provider

Request a monthly or quarterly report that covers: backup success rates, patch compliance percentage, open alerts and their status, ticket volume by category, and any proactive maintenance completed. If your provider can't or won't produce this, you're not getting managed support — you're getting helpdesk support with a different label.