Reliable Windows Service Monitoring

Catch service failures automatically before users notice anything is wrong

How do you monitor Windows services across your infrastructure?

Windows services are the backbone of most Microsoft environments. When DNS stops responding, IIS drops, or SQL Server hangs, the impact spreads fast and the diagnostic clock starts immediately. Continuous service status monitoring across servers and endpoints is how you catch those failures before they reach end users.

PRTG queries service status directly via WMI or SNMP, no agent required. The WMI Service sensor checks whether a specific service is running, stopped, or in an error state, and you identify services by display name or internal service name. Coverage includes IIS, SQL Server, DNS, Active Directory, Exchange Server, SharePoint, antivirus services, and custom applications. Supported systems: Windows Server 2008 R2 or later, plus Windows 10 and 11 endpoints, as long as the PRTG probe can reach them via WMI.

Download PRTG Trial

PRTG is compatible with all major vendors, products, and systems

Stay in Control of Windows Services Across Your Entire Infrastructure

Detect Service Failures Before Users Report Them

Manual checks don't scale. Across dozens of Windows servers and endpoints, staying ahead of service failures by logging in and looking isn't realistic. Also services can stop for all kinds of reasons: dependency failures, resource exhaustion, a patch that changed something it shouldn't have. By the time users start to report the issue, troubleshooting has already started too late.

PRTG's WMI Service sensor checks service status in real-time. The moment a service stops or enters an error state, notifications fire. You define which services matter, set the expected state, and the sensor handles continuous checking across your infrastructure. IT teams get time to investigate before end users notice anything.

Real-time service status monitoring via WMI across Windows servers and endpoints
Automatic alerts when services stop, fail to start, or change from expected state
Monitor by service name or display name for flexibility across Windows versions
Track startup type (automatic, manual, disabled) to verify proper configuration
Custom thresholds define acceptable service states per environment

Automate Service Restart and Recovery

Some service failures are transient. A brief memory spike, a network timeout, and the service is down until someone logs in to restart it. Outside business hours, that delay compounds.

PRTG connects notification triggers to PowerShell scripts to handle this automatically. When the WMI Service sensor first detects a stopped service, you can tell it to execute a predefined PowerShell script to attempt a service restart. PRTG logs the notification event on its side; any additional logging of the restart action itself must be handled within the script. This can run 24/7 and is an easy way to keep full control over which services get automatic restart and which require human review.

Worth noting: event log monitoring pairs well here. Combining the WMI Service sensor with the WMI Event Log sensor gives you the restart action and the context around why the failure happened in the first place.

Automated service restart via PowerShell script execution, triggered on sensor state change
Configurable notification triggers tied to specific service states
Monitor by service name or display name for flexibility across Windows versions
Historical data in dashboards shows service status and restart events for troubleshooting

See Why IT Professionals Trust PRTG

Start monitoring your infrastructure in minutes. No professional services, no complex configuration, no risk.

Free download

PRODUCT OVERVIEW

Centralize Visibility Across Distributed Windows Infrastructure

Running Windows infrastructure across regional offices or multiple data centers means the same service stack repeating everywhere: DNS, DHCP, file services, domain controllers. Getting centralized visibility without deploying agents or opening new firewall rules is the actual challenge.

PRTG handles this through a central installation with distributed remote probes at each site. The WMI Service sensor uses native Windows protocols, so there's nothing to install on monitored systems and no additional attack surface introduced. Active Directory replication, DNS servers, and file services across the network are all visible from one interface. For teams with local autonomy, each site is able run its own PRTG instance while corporate IT pulls aggregated views to their dashboard through the API.

Centralized dashboards across branch offices and data centers
No agent installation required; WMI is already present in Microsoft Windows
Remote probes for sites with limited WAN bandwidth
Track service dependencies across servers to map cascading failure scenarios
Role-based access for local and corporate teams in multi-site environments

Correlate Service Health with Performance Metrics

A service showing "Running" doesn't mean it's working. Services can hang or consume excessive CPU while still reporting active. Binary up/down monitoring misses this entirely.

PRTG combines service status with performance metrics from the same servers. The WMI Service sensor runs alongside CPU, memory, disk I/O, and event log sensors on the same device. When the SQL Server service is running but CPU hits 100%, both data points appear in context on the same dashboard. That correlation is usually the difference between spotting a performance bottleneck early and waiting for it to become an outage.

WMI Service sensors combined with CPU, memory, and disk monitoring on the same nodes
Service status correlated with Windows Event Log entries for faster root cause identification
SQL Server, IIS, and Exchange services monitored alongside application-specific performance counters
Custom sensors track service-specific metrics beyond basic running/stopped states
Historical data surfaces patterns between service restarts and resource exhaustion

How PRTG Monitors Windows Services

PRTG uses Windows Management Instrumentation (WMI) to query service status directly from the Windows operating system. Depending on the asset you want to monitor you can also use SNMP. No agent and no proprietary protocols required.

WMI Service Sensor

PRTG's WMI Service sensor uses WMI to query service status on the target Windows system. This helps you to identify the target service by its service name (the internal identifier, such as "W3SVC" for IIS) or display name (such as "World Wide Web Publishing Service"). The sensor reports the current service state, including running and stopped. For the full list of reported states, refer to the WMI Service sensor documentation. By default the scanning interval is 60 seconds and applies to WMI Service sensors like any other sensor. You can adjust this per sensor or per group, with shorter intervals available down to 30 seconds.

WMI Protocol and Authentication

When PRTG authenticates itself to Windows systems it uses domain credentials or local administrator accounts. The WMI connection runs over DCOM, using TCP port 135 plus dynamically assigned high ports. Be aware that your monitored Microsoft systems need to run Windows Server 2008 R2 or later. Both IPv4 and IPv6 addressing are supported. Domain credentials are the practical choice in enterprise environments where managing per-server credentials becomes a problem at scale.

Event Log Integration

Deploying our WMI Event Log sensor is a practical way to monitor event logs for service-related errors and warnings. As soon as a service fails, you see the specific error code, failure reason, and related events logged before or after it stopped. Pairing the event log sensor with service status sensors on the same device allows you to get the real-time state and the diagnostic history in one dashboard view.

Worth noting: the WMI Event Log sensor has a relatively high performance impact. Keep the number of these sensors per probe in check to avoid degrading overall monitoring performance.

Custom Script Sensors

For services where status alone isn't enough, PRTG supports the use of PowerShell script sensors that run your custom validation logic. Such a PowerShell script can verify that a service is actually responding to requests, check service dependencies, query service-specific metrics, or test an application endpoint. Results come back as custom channels with thresholds you define. This extends observability beyond what WMI provides natively.

free downLoad

Manual Service Checks vs. PRTG

FEATURE	Manual Approach Manual Approach	With PRTG With PRTG
Service Status Visibility	Manual Approach Log into each server, open Services console, scroll through the list	With PRTG Centralized dashboard shows all service statuses across infrastructure in real-time with color-coded indicators
Failure Detection	Manual Approach Wait for user complaints, then identify which service stopped	With PRTG Notifications fire based on notification triggers you configure on the sensor. When a trigger condition is met on the next scan, PRTG dispatches the alert through your configured channels (email, SMS, push, etc.).
Configuration Compliance	Manual Approach Track expected states in spreadsheets, verify manually after changes	With PRTG Define expected states in sensor configuration once; alerts when actual state doesn't match
Historical Tracking	Manual Approach Schedule after-hours checks or rely on monitoring windows	With PRTG Continuous monitoring with historical data showing when startup types changed or services were reconfigured
Service Recovery	Manual Approach Restart via RDP or PowerShell remoting, log manually in ticket system	With PRTG Automated restart through notification triggers; PRTG logs the notification event, and the PowerShell script handles restart-specific logging

free downLoad

We have found these sophisticated levels of monitoring to be highly effective, improving the end user’s experience of the systems and applications in use, giving us the opportunity to provide a proactive resolution rather than having the end user raise issues.

Saif Akil, Head of Service Management

Acurus

“Before PRTG, applications and hardware all gave messages, but all separately, so we had to search through hundreds of e-mails to find the problem. It was always only afterwards that we saw that something was going on within the infrastructure. To mitigate the issue, we also considered other software. PRTG stood out because of its user-friendliness, flexibility and minimal consultancy investment.”

Wim Vandenberghe, ICT Manager

Soenen Golfkarton

PRTG gives a birds-eye view of your network to troubleshoot problems or look at systems in their entirety that other solutions cannot – and I have looked at all of them.

Colin Metzler, Cybersecurity Analyst

Dayton Children’s Hospital

Paessler PRTG Network Monitor licenses & pricing

Choose the PRTG Network Monitor subscription that's best for you.

License Name	Price	License Details	Get started	Pricing Details
PRTG 500	^$200	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 50 devices
PRTG 1000	^$358	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 100 devices
PRTG 2500	^$742	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 250 devices
PRTG 5000	^$1,300	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 500 devices
PRTG 10000	^$1,642	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 1000 devices

Over 100,000 Customers Worldwide Love Paessler

Windows Service Monitoring: Frequently Asked Questions

Can PRTG monitor services on Windows 10 and Windows 11 workstations, or only servers?

PRTG monitors Windows services on both servers and workstations. The WMI Service sensor works with Windows 10, Windows 11, and Windows Server 2008 R2 or later. You need appropriate credentials (domain or local admin) and firewall rules that allow WMI traffic. Workstation monitoring is common for critical endpoints running specialized services or applications.

How does PRTG handle monitoring hundreds of services across multiple servers?

PRTG offers two mechanisms for deploying service sensors at scale: auto-discovery, which scans new devices and creates sensors automatically based on detected services, and device templates, which let you define a fixed set of sensors to apply to a device manually. These work independently; choose based on whether you want automated detection or a controlled, predefined sensor set.

What's the difference between monitoring by service name versus display name?

Service name is the internal Windows identifier, for example "MSSQLSERVER." Display name is the human-readable label, such as "SQL Server (MSSQLSERVER)." Service names stay consistent across systems and language packs; the display name of the service can vary between Windows versions or locales. PRTG supports both. The name of the service is the more reliable choice for production monitoring.

Can PRTG automatically restart a service if it stops unexpectedly?

Not natively, but you can set it up through notification triggers and an external PowerShell script. When the WMI Service sensor detects a stopped service, a configured notification trigger fires and executes the script, which handles the restart remotely. PRTG logs the notification event; the script itself is responsible for any detailed restart logging. If you need an audit trail, configure the script to write entries to the Windows Event Log or an external log file. You stay in control of which services get automated recovery and which require a human to intervene.

Does monitoring Windows services via WMI require opening specific firewall ports?

WMI uses TCP port 135 for the initial connection plus dynamically assigned ports, typically in the 49152-65535 range. In restrictive environments, you can limit the dynamic port range through Windows registry settings. Alternatively, deploy PRTG remote probes inside each network segment. Remote probes monitor local services and report back to the core server over HTTPS, requiring only outbound port 443.

How does PRTG handle service monitoring during planned maintenance or server reboots?

During a maintenance window, PRTG pauses the affected sensors entirely. No data is collected, and no alerts are triggered for the duration of the window. Monitoring resumes automatically when the window ends.