To monitor IIS server performance, track four layers: the server (CPU, memory, disk), the IIS worker process (w3wp.exe), the request pipeline (requests per second, queued and rejected requests, response time) and errors (HTTP 5xx rates). Collect these with Windows Performance Monitor counters and IIS logs, then send them to a monitoring tool that alerts on trends.
Key takeaways
- Requests queued, requests rejected and response time tell you more about user impact than CPU alone.
- IIS logs include a time-taken field by default, so you can measure slow URLs without extra tooling.
- Use Failed Request Tracing to capture the detail of slow or failing requests that logs only summarise.
appcmd list requestsshows the requests running right now, which helps when a site hangs.- For alerting and history, ship counters to Amazon CloudWatch, Azure Monitor or a tool such as Datadog.
Which IIS performance metrics should you monitor?
Start with a small set of counters that show load, saturation and errors. Add more only when you are investigating a specific problem.
| Area | Performance counter | What it tells you |
|---|---|---|
| Server | Processor: % Processor Time | Overall CPU pressure on the host |
| Server | Memory: Available MBytes | Whether the server is short of memory |
| Server | LogicalDisk: Avg. Disk sec/Read and sec/Write | Disk latency, often the cause of slow logging or file access |
| Worker process | Process (w3wp): % Processor Time, Private Bytes | CPU and memory used by each application pool; steady growth in Private Bytes suggests a leak |
| IIS | Web Service: Current Connections, Total Method Requests/sec | Traffic level per site |
| ASP.NET | ASP.NET: Requests Queued, Request Wait Time | Requests waiting for a thread; rising values mean the server is at its concurrency limit |
| ASP.NET | ASP.NET: Requests Rejected | Requests returned as HTTP 503 because the server was too busy |
| ASP.NET | ASP.NET Applications: Requests/Sec, Errors Total/Sec | Throughput and error rate per application |
| ASP.NET | ASP.NET: Application Restarts, Worker Process Restarts | Unplanned recycles that drop sessions and cause slow first requests |
Microsoft's ASP.NET performance counter reference explains why queued requests matter: when the counter rises linearly with client load, the server has reached the limit of concurrent requests it can process. Requests Rejected counts requests that returned HTTP 503 because resources were insufficient. These ASP.NET counters apply to .NET Framework applications. ASP.NET Core apps hosted in IIS expose their metrics through .NET event counters instead, so use dotnet-counters or your APM agent for those.
How to monitor IIS with built-in Windows tools
You can do a lot with what ships in Windows Server. These tools are enough for troubleshooting and for small estates.
Performance Monitor (PerfMon)
- Run
perfmonand open Performance Monitor. - Add the counters from the table above, choosing the w3wp instance for each application pool you care about.
- Create a Data Collector Set to log the counters to a file at a short sample interval, so you have a baseline before problems start.
- Compare the baseline with a slow period. A rise in queued requests with flat CPU points to blocking calls (database, external APIs) rather than lack of compute.
For scripted collection, typeperf writes the same counters to CSV from the command line.
IIS logs and response time
IIS writes W3C logs per site. According to the IIS logFile configuration reference, the default fields include TimeTaken, HttpStatus, HttpSubStatus and Win32Status. That gives you response time and status code for every request. Parse the logs with Log Parser, PowerShell or your log platform to find:
- The slowest URLs by 95th percentile time-taken.
- The share of 5xx responses per hour, broken down by substatus.
- Traffic spikes by client IP or user agent, which can indicate bots or attacks.
Failed Request Tracing
Failed Request Tracing (often called FREB) records the full pipeline of a request that matches a rule, such as any request slower than a set time or returning a 500. Each trace shows which module spent the time. Turn it on for a specific site and URL pattern while you investigate, then switch it off, because tracing every request adds overhead.
Currently executing requests
When a site hangs, check what IIS is processing right now. In IIS Manager, open Worker Processes and view current requests for a pool. From the command line, the AppCmd tool lists running requests with their URL and elapsed time, and can filter by site, application pool or worker process:
%systemroot%\system32\inetsrv\appcmd list requests /apppool.name:DefaultAppPool
Which tools can monitor IIS continuously?
Built-in tools are good for investigation, but they do not alert you at 03:00. For production, send counters and logs to a monitoring platform.
- Amazon CloudWatch agent: for IIS on EC2, the CloudWatch agent configuration takes a subsection per Windows performance object (Memory, Processor, LogicalDisk and others) and the counters to collect. It can also ship IIS log files to CloudWatch Logs.
- Azure Monitor: for Azure VMs and Arc-enabled servers, create a data collection rule to collect extra performance counters and IIS logs into a Log Analytics workspace.
- APM and observability tools: Datadog, Dynatrace, New Relic and SolarWinds collect IIS metrics and also trace requests into the application code and database, which shows why a request was slow, not just that it was.
Whatever tool you choose, alert on symptoms users feel first: rising response time, queued requests and 5xx error rate. Use CPU and memory alerts as supporting signals. If you also run the database on Windows, pair this with SQL Server performance monitoring.
Practical alert thresholds to start with
There are no universal limits; set thresholds from your own baseline. A sensible starting point:
- Requests Queued above zero for several minutes in a row.
- Any Requests Rejected (HTTP 503).
- 95th percentile time-taken well above the baseline for your key URLs.
- 5xx share of responses rising above its normal level.
- Private Bytes of a w3wp process growing steadily between recycles.
- Unplanned application or worker process restarts.
Review thresholds after every incident and after load tests. A load test shows where queued requests start rising, which is your real capacity limit.
How Opsio helps
Opsio provides 24/7 monitoring for Windows and IIS workloads running on AWS and Azure, including alert tuning and incident response. See our cloud monitoring and support services, or read the wider guide to monitoring Windows Server performance.
Frequently asked questions
How do I check IIS performance quickly?
Open Performance Monitor and add Requests Queued, Requests/Sec and the w3wp process CPU and memory counters, then check IIS Manager's Worker Processes view for long-running requests. Recent IIS logs show response times per URL in the time-taken field.
What does a high Requests Queued value mean?
Requests are waiting for a free thread. That usually means the application is blocked on a slow dependency, such as a database or external API, or the server has reached its concurrency limit.
How do I find slow pages in IIS?
Analyse the time-taken field in the IIS logs to rank URLs by response time, then enable Failed Request Tracing for the slowest URLs to see which module spends the time.
Can I monitor IIS with Amazon CloudWatch?
Yes. Install the CloudWatch agent on the Windows server, list the IIS and ASP.NET performance counters in its configuration, and add the IIS log folder as a log source.
Do the ASP.NET counters work for ASP.NET Core?
No. The classic ASP.NET counters cover .NET Framework applications. ASP.NET Core exposes metrics through .NET event counters, which you read with dotnet-counters or an APM agent.
Related reading
Written By

Country Manager, Sweden
Johan leads Opsio's Sweden operations, driving AI adoption, DevOps transformation, security strategy, and cloud solutioning for Nordic enterprises. With 12+ years in enterprise cloud infrastructure, he has delivered 200+ projects across AWS, Azure, and GCP — specialising in Well-Architected reviews, landing zone design, and multi-cloud strategy.
Editorial standards: This article was written by the cloud practitioner named in the byline above. We revise it when the technology or regulation it covers changes; the dates on this page show the latest update. Opsio maintains editorial independence.