Windows Server Monitoring: The Half Perfmon Misses

Windows server monitoring splits cleanly into two jobs, and most teams only staff one of them. The in-box Microsoft tools tell you how the machine feels from the inside. Nothing on the box can tell you whether the services it publishes are still answering from the outside, because a dead machine cannot report its own death.

What the in-box tools already give you

Microsoft ships a competent local stack and charges nothing extra for it. Microsoft's own training module covers Performance Monitor for counters and Resource Monitor for per-process CPU, disk, network and memory. It adds Reliability Monitor for a fault timeline, data collector sets for scheduled capture, and System Insights for capacity forecasting. Windows Admin Center wraps most of it in a browser and is described as a remote management tool at no extra cost.

That stack answers questions about resources well. Which process ate the page file, when the disk queue length started climbing, which driver crashed at 02:14. Microsoft's performance tuning guidance explains which counters are worth sampling and which are noise.

It shares one property with every agent-based product in this space. The observer lives on the thing being observed. When the host loses its NIC, its default route or its power, the counters stop and the last data point looks healthy.

The second job: watching the published services

Every Windows Server in production publishes ports to someone. Remote Desktop on 3389, IIS on 80 and 443, SMB file shares on 445, SQL Server on 1433, and the DNS or Active Directory roles the domain depends on. Those ports are what other people experience as "the server".

An external check opens a connection to the port from a network you do not control and records whether it answered. No software is installed on the host. The verdict comes from the same direction your users come from, which is the only direction that settles an argument about whether something was reachable.

We tested this against a box behind a misconfigured Windows Firewall rule. Local counters were flat and healthy for eleven minutes while 445 refused every connection from outside the subnet. The machine was fine. The service was not.

Mapping Windows roles to check types

Pick the check that matches what the role actually promises, not the one that is easiest to configure.

Windows role or service	Port	Check type	What a failure means
IIS website	443	http or keyword	The site is down, or serving the wrong content
IIS certificate	443	ssl	The certificate is expiring or the chain broke
Remote Desktop	3389	tcp	Nobody can administer the box remotely
SMB file share	445	tcp	Mapped drives will fail across the estate
SQL Server	1433	tcp	Applications lose their data tier
DNS role	53	dns	Name resolution fails for everything downstream
Domain controller reachability	n/a	ping	The host is off the network entirely

Exposing 3389 or 445 to the public internet is a separate and worse problem. If those ports are reachable only over a VPN, check them from inside that boundary or check the VPN endpoint instead.

Setting up the checks

Four steps, and the whole thing takes less time than installing an agent would.

1. List the ports each server publishes, and who consumes them.
2. Create one check per promise, not one per machine. A file server with a web console needs two.
3. Pick two probe regions near your users, from the six available as of September 2026.
4. Route the alert somewhere a person reads at 3am, not to a mailbox nobody watches.

A TCP check needs the port field alongside the target. This one watches a SQL Server listener from London and Singapore.

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "sql01 listener",
    "type": "tcp",
    "target": "sql01.example.com",
    "port": 1433,
    "intervalSec": 60,
    "regions": ["london", "singapore"],
    "alertAfterCycles": 2
  }'

If your firewall only admits known sources, the egress addresses for every region are published on the probe IPs page, and allowlisting them is the first step people forget. Port semantics and what a refused connection really means are covered in port monitoring.

What about scheduled tasks?

A Windows Scheduled Task that stops running is invisible to both halves above. No port changes, no counter moves, and the failure is silence. Heartbeat checks invert the direction: the task calls a URL when it succeeds, and the alert fires when the call does not arrive.

Add one line to the end of the script the task runs.

Invoke-RestMethod -Method Post -Uri "https://uptimeroom.com/api/heartbeat/<token>"

Set the expected period to the task's schedule plus a grace window that covers a slow run. The tuning details are the same as any other job and are laid out in heartbeat monitoring.

How often should Windows server monitoring run?

Sixty seconds is the right default for anything a person depends on during the working day. Detection time is bounded by the interval, so a five-minute check means a five-minute worst case before anyone knows. A 30-second interval is available on paid plans as of September 2026, and it is worth it for the one or two services that carry revenue.

We prefer to require agreement before paging. A single failed connection from one probe is usually a transient route, not an outage, and confirming from a second region removes most of that noise. Two regions have to agree on the free plan, as of September 2026.

Interval and confirmation interact. A fast check with no confirmation produces a fast wrong answer, which is worse than a slow right one.

Common mistakes

Watching the machine and calling it done. Windows server monitoring that only reads local counters cannot see a firewall rule, a DNS change or an upstream route withdrawal. Those are the outages that last longest, because nothing on the host reports them.

Checking 443 and assuming the site works. A default IIS page returns 200 happily while your application pool is stopped. Assert on a string that only your application renders.

Ignoring certificate expiry until it bites. An expired certificate on a renewal cycle nobody owns takes a site down as thoroughly as a crashed process. An ssl check with a warning window gives you weeks of notice.

One alert route for everything. A file share going quiet at 2am and a disk warning at 2pm are not the same event. Route them differently, or people learn to ignore both. The mechanics of what a failed check actually proves are in downtime explained.

Treat the two halves as a pair. Keep Performance Monitor and Windows Admin Center for the questions that start with why, and put an external check on every port your estate promises to answer. That combination is what good Windows server monitoring looks like in practice. Start with the three ports your estate would notice first, and compare what the pricing page allows against how many promises your servers actually make.