Web & Application Servers
    Updated May 2026
    IIS logo

    IIS Monitoring

    Monitor IIS application pool recycling, HTTP.SYS request queue depth, w3wp.exe per-pool CPU and memory, ASP.NET request execution time,.NET CLR GC pressure in real time.

    Why monitor IIS?

    IIS runs the .NET ecosystem — ASP.NET, SharePoint, Exchange, MS Dynamics, and custom Windows workloads. Application pools recycle silently, HTTP.SYS queues fill, and 503s appear without obvious cause. Monitoring exposes the actual trigger so you stop debugging from event logs after the fact.

    Auto-discovery via Xitogent on Windows Server
    Per-application-pool health, recycling cause, and Rapid-Fail Protection visibility
    HTTP.SYS request queue depth, arrival rate, and rejection counters
    w3wp.exe per-pool CPU, Working Set, and Private Bytes tracking
    ASP.NET Framework + ASP.NET Core (via ANCM in-process / out-of-process) coverage
    .NET CLR GC pressure (% Time in GC, Gen 0/1/2 collections, LOH size)
    HTTP 4xx/5xx error rate per site
    Native Windows Server agent — no WMI proxy required
    1-minute metric collection intervals out of the box
    Historical data retention for capacity planning and post-incident review
    What is IIS monitoring?

    IIS monitoring, explained

    IIS monitoring catches application-pool recycling storms, HTTP.SYS request-queue buildup, and 503 trips before they hit your users — including the unexpected recycles that always seem to happen at 3am. For ASP.NET workloads on Windows Server, per-pool visibility is the difference between debugging a one-line event-log entry and triaging an opaque outage. Xitoring runs as a native Windows agent, reads the same Performance Monitor counters and routes alerts to your existing on-call rotation.

    Metrics

    What we monitor

    Current Connections (Web Service)

    Active client connections per site, from the `Web Service` PerfMon category. The first number to watch for connection saturation.

    Get/Post Requests / sec

    HTTP request throughput per site, broken down by method. Sudden Get vs Post divergence often signals scraping or form-spam attacks.

    Bytes Sent / Received per sec

    Network throughput per site. Correlates with connection-state metrics to surface bandwidth-bound vs request-rate-bound bottlenecks.

    ArrivalRate (HTTP.SYS Queue)

    Rate of requests entering the kernel-mode HTTP.SYS queue — counted before user-mode w3wp picks them up. Spikes here precede every 503 storm.

    CurrentQueueSize

    Requests currently waiting in the HTTP.SYS queue per app pool. Sustained non-zero values mean workers can't keep up with arrivals.

    RejectedRequests

    Requests HTTP.SYS dropped because the queue exceeded its limit. Any non-zero rate is a hard signal to scale workers or raise the queue limit.

    App Pool Status & Recycling

    Per-pool health state and recycling cause (timer, request count, memory threshold, Rapid-Fail Protection). Unexpected recycles point at memory leaks or upstream failures.

    ASP.NET Request Execution Time

    Average time ASP.NET spends running each request, separate from queuing. Diverging from Service Uptime baseline localizes latency to app code vs infrastructure.

    ASP.NET Requests Queued

    Requests waiting on the managed ASP.NET worker queue (separate from HTTP.SYS). High values point to thread-pool starvation in CLR-bound workloads.

    .NET CLR % Time in GC

    Percentage of CPU spent in garbage collection per worker. Above 5–10% means GC pressure is driving latency — track with Gen 0/1/2 collection counts.

    w3wp.exe CPU / Working Set

    Per-worker CPU usage and resident memory from the `Process` PerfMon category. Tagged by app pool so you see which workload is consuming what.

    HTTP 4xx / 5xx per sec

    Error rate per site. A 5xx spike with stable request rate points at app-pool failures or backend dependencies, not traffic.

    Triggers & Alerts

    Configurable alert triggers

    Set up custom triggers in your dashboard to get notified the moment IIS metrics cross your defined thresholds.

    IIS monitoring trigger configuration dashboard

    Request Queue

    critical

    Fires when queue depth exceeds threshold, indicating processing bottleneck.

    App Pool Recycling

    warning

    Alerts when application pool recycles unexpectedly.

    HTTP Error Rate

    warning

    Triggers when error rate spikes.

    Worker Process CPU

    critical

    Fires on high CPU usage in worker processes.

    Active Connections

    warning

    Alerts when connections approach server limits.

    01

    Importance of IIS Monitoring

    IIS runs mission-critical.NET applications and corporate intranets. Without monitoring, application pool crashes, queue buildup, and memory leaks can cause outages.

    • Detect app pool crashes before users are affected
    • Monitor request queues to prevent timeouts
    • Track worker process memory to prevent leaks
    • Identify HTTP error spikes early
    IIS monitoring dashboard
    IIS worker process analytics
    02

    Why Choose Xitoring

    Native Windows Server support with easy installation and enterprise-grade monitoring.

    • Native Windows installer
    • 15+ global monitoring nodes
    • Unified dashboard for all services
    • Multi-channel alerting
    • Historical data retention
    Xitoring IIS overview
    Alert configuration
    Use cases

    Common IIS monitoring scenarios

    Where IIS typically runs today — and what could go wrong if no one's watching.

    Established .NET business apps

    Long-running .NET apps tend to develop slow memory leaks that surface only at the worst times — overnight restarts, mysterious slowdowns, weekend incidents. We track the early signs so the team can fix the root cause on their schedule, not the app's.

    Modern .NET apps in production

    Newer .NET apps run more of their code directly inside the web server, which means an app issue can take the whole site down faster. We watch the app and the web server as one unit so problems get isolated to the right layer immediately.

    Front door for SharePoint, Exchange, or internal sites

    When IIS is the gateway to enterprise apps like SharePoint or Exchange, an outage stops the whole company. We catch the signs of an overloaded gateway or a failing backend so the team can intervene before staff start filing tickets.

    Before you start

    Prerequisites for IIS

    Make sure you've got these in place — most installs are a 60-second job once they are.

    • Windows Server 2016 / 2019 / 2022 / 2025 with the IIS role installed
    • IIS performance counters enabled (Web Service, HTTP Service Request Queues, ASP.NET, .NET CLR Memory, Process)
    • Administrator access to install the Xitogent Windows agent
    Setup Guide

    Get started in minutes

    1

    Install Xitogent on your IIS host

    Run the Xitogent Windows installer on the IIS server. The MSI registers Xitogent as a Windows service with permission to read IIS Performance Counters.

    # Download from https://xitoring.com/install.exe # Run the installer as Administrator
    2

    Verify IIS Performance Counters

    IIS exposes runtime metrics through Windows Performance Counters. Confirm the Web Service counter class is present by running `Get-WmiObject Win32_PerfFormattedData_W3SVC_WebService -filter "Name='_Total'"` in PowerShell. If the class is missing, run `install-windowsfeature web-common-http`.

    xitogent integrate
    3

    Enable the IIS integration

    Use the Xitoring dashboard or CLI to enable the IIS integration. Xitogent enumerates each application pool and site automatically, so per-pool metrics are available without further setup.

    4

    Configure alert thresholds (optional)

    Set custom thresholds for Request Queue Length, App Pool Recycling, or HTTP Error Rate to catch capacity and stability issues per pool.

    5

    Verify it's working

    Run this command on the server to confirm Xitogent picked up the integration. Fresh metrics will start streaming to your dashboard within ~30 seconds.

    sudo xitogent status

    Frequently asked questions

    What is IIS monitoring?
    IIS monitoring is the continuous collection of Internet Information Services performance data — Web Service counters (Current Connections, Bytes/sec, Requests/sec), HTTP.SYS request-queue counters (ArrivalRate, CurrentQueueSize, RejectedRequests), ASP.NET execution and queue counters,.NET CLR GC counters, and per-`w3wp.exe` Process counters — combined with alerting on app-pool recycles and 503 trips.
    How do I enable IIS performance counters?
    IIS counters install with the Web Server role. Verify with PowerShell: `Get-Counter "\Web Service(_Total)\Current Connections"`. If you only see basic categories, run `Install-WindowsFeature Web-Common-Http,Web-Performance` and reboot. Xitogent reads these counters directly via the Windows perf-counter API — no WMI proxy or HTTP endpoint required.
    How do I monitor application pool recycling?
    Application pools recycle on four triggers: a periodic timer (default 1740 minutes), a request-count threshold, a Private Bytes / Virtual Memory threshold, or Rapid-Fail Protection (default: 5 worker failures in 5 minutes → pool stops + 503 Service Unavailable). Xitogent records the recycle cause for each event and exposes per-pool recycle frequency — so you can tell scheduled maintenance from a memory-leak symptom at a glance.
    What is the difference between IIS classic and integrated pipeline?
    Integrated pipeline (the default since IIS 7) routes every request through the unified IIS + ASP.NET pipeline — one set of HTTP modules handles auth, logging, and request processing for both static and managed content. Classic pipeline runs ASP.NET as an ISAPI extension behind the legacy IIS pipeline (two separate request paths). Classic mode is deprecated and slower; new apps should use Integrated. Xitogent monitors both, but Integrated exposes more managed-pipeline counters.
    How do I monitor the HTTP.SYS request queue?
    The `HTTP Service Request Queues` PerfMon category exposes `ArrivalRate` (rate of incoming requests at the kernel), `CurrentQueueSize` (requests waiting for a worker), and `RejectedRequests` (dropped because the queue limit was hit). A non-zero RejectedRequests rate is the single best leading indicator of HTTP 503 trips. Alert there and on `CurrentQueueSize > MaxQueueLength × 0.8`.
    How do I monitor ASP.NET Core apps hosted on IIS?
    ASP.NET Core uses the ASP.NET Core Module (ANCM). In-process hosting (the default since 2.2) runs Kestrel inside `w3wp.exe` — monitor it like any other app pool, plus the `IISHttpServer` provider for ANCM-specific metrics. Out-of-process hosting runs Kestrel separately and proxies through IIS — track both the `w3wp.exe` proxy and the backend Kestrel process.
    What causes HTTP 503 Service Unavailable in IIS?
    Three main causes: (1) the application pool stopped or crashed (often Rapid-Fail Protection triggered), (2) HTTP.SYS rejected requests because the queue exceeded `MaxQueueLength`, (3) the worker process is recycling and not yet ready. Each shows a different signal: pool status, RejectedRequests counter, or recycle event. Xitogent surfaces all three so triage takes minutes, not hours.
    Can I monitor IIS on Windows Server Core?
    Yes. Xitogent works identically on Windows Server Core and full Server installations — it reads performance counters via the same API. Server Core is actually the recommended deployment for production IIS workloads since it reduces attack surface and recycle-triggering OS updates.
    How often are metrics collected?
    Every 60 seconds by default, with sub-minute polling available for incident response. Per-pool recycle events are captured the moment they happen via Windows event subscriptions (no polling delay), so 503 root cause is visible immediately rather than at the next sample interval.

    Start monitoring IIS today

    Set up in under 60 seconds. No credit card required. Full metrics from day one.

    Start Free Trial

    Keep exploring

    Related Integrations