GuidesWindows Server

How to monitor Windows Server performance

Updated 17 October 2026 · 8 minute read

To monitor Windows Server performance, watch six things: CPU (including the processor queue), memory (available MB and paging), disk space and disk latency, network throughput and errors, the services your applications depend on, and errors in the Windows Event Log. Collect them every 15 to 60 seconds, keep the history, and alert when a value stays past a threshold for several minutes rather than on a single spike.

This guide explains each metric, gives starting thresholds, and shows how to check them with the tools built into Windows.

Why monitor Windows Server

Most server problems give warning before they cause an outage. A disk fills over weeks. Memory use creeps up after each deployment. A service crashes and restarts quietly every night. Monitoring turns these slow trends into early alerts, and gives you a history to compare against when something does break.

The key Windows Server metrics

CPU

\Processor(_Total)\% Processor Time shows how busy the processors are. High CPU on its own is not a problem; a server running at 90% while its work finishes on time is simply well used. The more useful signal is \System\Processor Queue Length: the number of threads waiting for a processor. A queue that stays above about two per core means work is waiting, and users will feel it.

Memory

Watch \Memory\Available MBytes, the memory that can be given to processes straight away. Windows uses spare memory for its file cache, so "used" memory looks high on a healthy server. Available memory is the honest number.

Pair it with \Memory\Pages/sec and \Memory\% Committed Bytes In Use. Paging on its own is normal, because Windows also pages when it reads memory-mapped files. Heavy paging while available memory is low means the server is short of RAM. Committed bytes close to the commit limit means the page file and RAM are nearly exhausted, and allocations will start to fail.

Disk space and disk latency

Check free space on every volume with \LogicalDisk(*)\% Free Space. A full system drive can stop Windows Update, logging and even sign-in, and a full data drive stops databases.

Space is only half the picture. \PhysicalDisk(*)\Avg. Disk sec/Read and Avg. Disk sec/Write show how long each operation takes, in seconds (0.020 is 20 ms). Latency is the best single sign of a storage bottleneck. Current Disk Queue Length helps too, but on SSDs and SAN storage a queue of several requests can be perfectly healthy, so judge it alongside latency.

Network

\Network Interface(*)\Bytes Total/sec compared with the link speed shows how full the connection is. Also watch Packets Received Errors and Packets Outbound Discarded. These should be at or near zero; a rising count usually points at a driver, cable, switch port or NIC teaming problem.

Services

Your application depends on Windows services: IIS (W3SVC), SQL Server, your own services and the agents you rely on. Any service set to start automatically that is not running deserves attention. The Service Control Manager records unexpected stops in the System log, as event IDs 7031 and 7034.

Windows Event Log errors

The System and Application logs record disk errors, driver failures, application crashes and unexpected shutdowns. Some event IDs worth knowing:

  • 41 (Kernel-Power) and 6008 — the server restarted without a clean shutdown.
  • 7031 and 7034 — a service terminated unexpectedly.
  • 1000 (Application Error) — an application crashed.
  • 153 and 129 — storage I/O was retried or reset, often an early sign of disk or controller trouble.

Sensible alert thresholds

These are starting points. Adjust them once you know each server's normal behaviour, and require the condition to last several minutes before alerting.

MetricWarningCritical
CPU (% Processor Time)Above 85% for 10 minutesAbove 95% for 10 minutes
Processor Queue LengthAbove 2 per core for 10 minutesAbove 4 per core for 10 minutes
Available memoryBelow 15% of RAMBelow 5% of RAM or 500 MB
% Committed Bytes In UseAbove 85%Above 95%
Disk free spaceBelow 20%Below 10%
Disk latency (sec/Read or sec/Write)Above 20 ms for 10 minutesAbove 50 ms for 10 minutes
Network useAbove 70% of link speedAbove 90% of link speed
Automatic service stopped—Any, for more than 2 minutes
Server not reporting—No data for 5 minutes

For SSD and NVMe storage, latency consistently above 10 ms is already worth investigating.

Built-in tools for checking performance

Task Manager and Resource Monitor

Task Manager (Ctrl+Shift+Esc) gives a quick view of CPU, memory, disk and network, and the Details tab shows which process is responsible. Resource Monitor (resmon) goes further: disk activity per file, response time per disk, and which process owns each network connection. Both are good for a live problem on one server. Neither keeps history.

Performance Monitor

Performance Monitor (perfmon) charts any counter and can record counters to a file with a Data Collector Set. Recording a baseline over a normal week is the most useful thing you can do with it. You can create one from the command line:

logman create counter Baseline -c "\Processor(_Total)\% Processor Time" "\System\Processor Queue Length" "\Memory\Available MBytes" "\LogicalDisk(*)\% Free Space" -si 00:00:15 -o C:\PerfLogs\Baseline
logman start Baseline

PowerShell and Get-Counter

Get-Counter reads the same counters from PowerShell, locally or from a remote server with -ComputerName. Sample CPU and the processor queue every 5 seconds for one minute:

Get-Counter -Counter '\Processor(_Total)\% Processor Time','\System\Processor Queue Length' -SampleInterval 5 -MaxSamples 12

Memory and paging:

Get-Counter '\Memory\Available MBytes','\Memory\Pages/sec','\Memory\% Committed Bytes In Use'

Disk space and latency:

Get-Counter '\LogicalDisk(*)\% Free Space','\PhysicalDisk(*)\Avg. Disk sec/Read','\PhysicalDisk(*)\Avg. Disk sec/Write'

Automatic services that are not running, and error events from the last 24 hours:

Get-Service | Where-Object { $_.StartType -eq 'Automatic' -and $_.Status -ne 'Running' }

Get-WinEvent -FilterHashtable @{ LogName = 'System','Application'; Level = 1,2; StartTime = (Get-Date).AddHours(-24) } |
  Select-Object TimeCreated, Id, ProviderName, Message -First 20

Counter names are translated on non-English editions of Windows, so a script written with English names may fail there. A few automatic services also stop on their own once their work is done; add them to an exclusion list.

Why a central tool helps when you run many servers

The built-in tools work well for one server and one problem. They become hard to use when you run ten or a hundred servers:

  • Nobody watches a perfmon chart at 3 a.m. You need alerts that reach a person.
  • Logs and counter files stay on each server, so comparing servers means logging in to each one.
  • History disappears when a server is rebuilt, which is exactly when you want it.
  • Scheduled PowerShell scripts drift, fail silently and need maintaining.

A central monitoring tool collects the same metrics and logs from every server, keeps the history, and alerts on the thresholds above. Whatever tool you choose, check that the agent is light, needs no inbound firewall rules, and can collect the Event Log as well as metrics.

Monitor Windows Server with Televane

Televane infrastructure monitoring uses a small agent that runs as a Windows service on Windows Server 2016, 2019, 2022 and 2025 and on Windows 10/11. It sends CPU, memory, disk, network and top-process metrics every 15 seconds, connects outbound over HTTPS only and opens no ports. Its resources are capped at about one CPU core and 128 MB of memory.

  1. Create a free account. New organizations get a 14-day Pro trial with no card.
  2. In the portal open Add data, choose Windows and copy the installation command.
  3. Run it in PowerShell as Administrator. The server appears under Hosts within a minute or two. The Windows agent guide covers requirements and troubleshooting.
  4. To collect the Event Log, list the System and Application channels in the agent's agent.json with a minimum level such as warning. The events then appear in Logs, with passwords and tokens masked on the server.
  5. In Alerts, start from templates such as Host CPU critical and Host not reporting, and add a log alert for service-stop events such as 7031 and 7034. Notifications can go to email, Slack, Microsoft Teams, PagerDuty or a webhook. See alerts and incidents.

For deeper checks on one server, such as the processor queue or per-disk latency, Get-Counter and Performance Monitor remain the right tools. Televane charges for the data you send, not per server; see pricing.

Frequently asked questions

What are the most important Windows Server performance counters?

% Processor Time and Processor Queue Length for CPU, Available MBytes and % Committed Bytes In Use for memory, % Free Space and Avg. Disk sec/Read and sec/Write for disks, and Bytes Total/sec with packet errors for the network.

How do I check CPU usage on Windows Server with PowerShell?

Run Get-Counter '\Processor(_Total)\% Processor Time' -SampleInterval 5 -MaxSamples 12 to sample CPU every 5 seconds for one minute. Add '\System\Processor Queue Length' to see whether work is waiting.

What is a good disk latency for Windows Server?

On spinning disks, average read and write times under 20 ms are healthy and above 50 ms is a problem. On SSD and NVMe storage, sustained latency above 10 ms is worth investigating.

Is Performance Monitor enough to monitor Windows Server?

For a single server and a live problem, often yes. For several servers you also need central history, Event Log collection and alerts that reach a person, which Performance Monitor does not provide on its own.