For IIS 502 or 503, identify the responding layer, full substatus and matching request before restarting anything. A 503 can mean an unavailable pool or a queue limit; a 502 requires the module and ARR version to interpret it. If the request is absent from the site log, inspect HTTPERR as well as upstream logs.
This is source-researched, untested guidance for an IIS 10 reference environment. ARR-specific steps apply only where ARR is actually installed. Some Microsoft diagnostic examples describe older releases; their example timeout values and platform details are not assumed to be current configuration defaults.
Map the request before interpreting the status
Write down the public hostname, TLS termination point, proxy or load balancer, IIS site, application, application pool and backend service. A request may cross several machines before reaching the code that performs the business operation.
Record which node answered and whether failures affect all requests or only one application path. A working static page can coexist with a broken database-backed operation. Conversely, one unhealthy backend can create intermittent errors while other nodes continue serving.
Preserve the client’s request time, method and a safe correlation identifier. Avoid recording authentication headers, cookies or customer payloads in an unrestricted diagnostic packet. Where logs already contain sensitive request details, retain them under the application’s incident-access controls.
Do not begin by raising every timeout. First establish which component returned the error and what it was waiting for. A larger timeout can merely hold failed work in memory for longer.
Read the complete IIS result
Microsoft’s HTTP status reference distinguishes several IIS substatuses. In its documented cases, 503.0 means the application pool is unavailable, while other 503 substatuses identify request or framework queue conditions. A bare browser “503” does not select one of these causes.
For ARR, the reference distinguishes forwarding and no-server conditions and also records version-specific status descriptions. Match the installed ARR version and the log evidence rather than assuming every 502 means the backend application crashed.
Open the relevant existing IIS log for the failed request and inspect the fields actually configured. Microsoft’s ARR troubleshooting guide uses sc-status, sc-substatus, sc-win32-status and time-taken together. Preserve the log header so the fields cannot be misread after columns are omitted from an excerpt.
For example, Microsoft’s documented ARR case combines 502.3 with Win32 status 12002, identifying a WinHTTP timeout. That is a sourced example, not an observed result here and not proof that every 502.3 has the same cause. Keep the actual status and duration from the affected request.
If the expected request is absent, confirm the site, node, logging configuration and time basis before concluding that IIS never saw it. The request may have failed upstream or reached a different instance. Missing retained logs are an evidence gap.
Use the substatus and inspect the pool
Microsoft's IIS table distinguishes these 503 results S1:
| Code | Meaning |
|---|---|
| 503.0 | Application pool unavailable |
| 503.2 | Concurrent request limit exceeded |
| 503.3 | ASP.NET queue full |
| 503.4 | FastCGI queue full |
For 502, module/version scope matters S1:
| Code | General table; ARR 3.0.1916-specific meaning where different |
|---|---|
| 502.1 | CGI timeout |
| 502.2 | Premature exit; ARR: map request failure |
| 502.3 | ARR forwarder connection error; ARR 3.0.1916: WinHTTP asynchronous completion failure |
| 502.4 | ARR: no server |
| 502.5 | ARR 3.0.1916: WebSocket failure |
| 502.6 | ARR 3.0.1916: forwarded request failure |
| 502.7 | ARR 3.0.1916: execute request failure |
Do not apply ARR descriptions to a hosting module that defines its own substatuses. This article covers general classification and ARR forwarding, not every module's startup repair.
HTTP.sys can record failures outside the site's IIS log. Microsoft's ARR example locates a dropped request in HTTPERR S2. Ask the IIS owner for the configured HTTP.sys error-log location, then correlate time, endpoint and reason; an empty site log alone does not prove the request never reached Windows.
Untested IIS 10 diagnostic, in an authorised elevated Command Prompt; substitute the affected pool R1:
%systemroot%\system32\inetsrv\appcmd list apppool "ExamplePool" /text:state
In IIS Manager, select that application pool, Advanced Settings → Rapid-Fail Protection, and record Enabled, Failure Interval and Maximum Failures. Microsoft documents defaults of enabled, five minutes and five failures; record the actual values S3. Avoid dumping complete pool configuration into tickets because it can expose account details.
The failure setting loadBalancerCapabilities defaults to HttpLevel: a 503 response can leave a non-HTTP-aware balancer treating the node as available. TcpLevel terminates the TCP connection instead S3. Inspect the health-check contract before any change; neither setting repairs the worker failure.
Investigate an unavailable application pool
In IIS Manager, identify the pool assigned to the affected application and inspect its state. Check Windows application and service events for the same interval. A stopped pool is an observation; the next question is why it stopped or could not start.
Review recent application deployments, pool identity changes, required configuration and dependency access. Compare the failing pool with its recorded supported configuration. Do not move the application into another pool with broader rights simply to see whether it starts.
Microsoft documents rapid-fail protection as a mechanism that reacts to repeated worker-process failures within a configured interval S3. Inspect the actual enabled state, interval and failure count settings. Do not assume the default values quoted in a reference describe the server under investigation.
If rapid-fail protection disabled the pool, preserve the worker failure evidence. Repeatedly starting the pool or disabling the protection does not correct the crash. It can create a repeating failure cycle that consumes resources and obscures the original event.
The failure-settings schema also distinguishes behaviour presented to load balancers when a worker cannot start. A health system that only sees a TCP listener can interpret the node differently from an HTTP-aware check. Record the actual observation boundary before blaming the load balancer.
Investigate an ARR forwarding failure
For an ARR path, identify the upstream server selected for the failed request. Inspect the proxy’s routing evidence and the backend’s corresponding request log. The Microsoft guide describes using ARR_SERVER_ROUTED and X-ARR-LOG-ID in tracing to connect those observations S2.
A backend request that completes after the proxy gives up is a different case from a backend that never received the request. The first calls for investigation of application duration, dependency waits and the agreed timeout design. The second points towards the proxy-to-backend path, listener or connection establishment.
If the backend logged a response, compare its time and status with the proxy result. Check whether the connection was interrupted or the response could not be forwarded. Do not decide that the application succeeded solely because a backend log recorded a response when the client received an error.
Use the approved administration path to inspect backend service health. A direct test must preserve the expected hostname, authentication and protocol where relevant. Testing an IP address under an administrator identity can bypass the conditions that fail in the real path.
Do not open the backend broadly to the internet to make a diagnostic easier. The needed question is whether the actual proxy can reach the actual service under the intended trust and access configuration.
Add tracing deliberately when existing logs are insufficient
Microsoft’s ARR investigation uses Failed Request Tracing to inspect the request sequence S2. Enabling tracing is a configuration change that can increase log volume and capture request details. Give it a narrow site, status/path scope, bounded collection window and protected destination.
Record the previous tracing configuration, available space and who will disable the temporary collection. Reproduce one approved synthetic request where possible. Stop once sufficient evidence exists rather than leaving verbose tracing running indefinitely.
Correlate the trace with application logs and dependency observations. If a request waits on SQL, identity or an external service, pass that exact request interval to the relevant owner. An IIS error can be where the failure becomes visible, not necessarily the layer where it began.
The article provides no tracing-enablement script because installed modules, schema and retention requirements vary. Review the supported UI or command help for the actual release before changing collection. No tracing was enabled for this draft.
Correct one established cause
A worker-process crash needs its application or module cause investigated. An invalid identity or inaccessible dependency needs the specific access configuration corrected. A queue limit reached under real demand needs workload and capacity analysis. These are different repairs despite similar user-facing errors.
If the evidence supports changing a timeout, document why the business operation legitimately takes that long, which component owns the limit and what happens to abandoned requests. Merely choosing a larger number can conceal an application regression or increase pressure during an outage.
Apply the approved correction to an isolated or staged target first. Preserve the previous application build and configuration. A server-wide restart should not be the default reversal for a change affecting one pool or one route.
If a temporary restart is required to recover service, record it as containment and retain the root-cause action. Do not call the incident resolved solely because requests succeed immediately after a restart.
Verify the user’s operation and the supporting evidence
Replay the original synthetic operation through the normal client entry point. Confirm the correct application result, destination and response status. Repeat under a representative, approved workload rather than testing only a quiet homepage.
Inspect the matching proxy, IIS and application records. Check that the pool remains healthy, no new rapid-fail cycle appears and the relevant dependency completes within the agreed service behaviour. Keep failed attempts in the result rather than reporting only the successful requests.
Where multiple backend nodes exist, verify each intended route through supported controls. A successful request to one healthy server does not establish that the repaired node serves correctly.
Restore temporary tracing settings and retain the bounded evidence. The final incident record should state the symptom, established failing layer, correction and measured acceptance scope. A generic “IIS restarted” entry is not enough for the next operator.
Limitations
IIS 10 is the reference environment. ARR’s documented code mapping is explicitly versioned; hosting-module startup failures need their own reference. No recycling, tracing configuration or rapid-fail protection change is executed here.
Acceptance checklist
- Responder, module/version and full status tuple identified.
- Site, HTTPERR, proxy and event evidence correlated where relevant.
- Pool state and effective failure settings recorded.
- Application operation and balancer health verified after the approved repair.
Learning notes
- Status, substatus and platform error fields narrow different failure boundaries.
- Rapid-fail protection is evidence of a worker problem, not the problem itself.
- A backend completing work does not prove the original client received a usable response.
Related reading: Renew IIS TLS Certificates and Verify the Live Endpoint; Server Up, Application Unusable: Build Better Health Checks.
Sources and review status
Sources accessed 30 October 2026. Exact displayed dates, scope and claim mapping are in the accompanying evidence file. Revised after independent review; independent recheck pending. All examples remain untested and no lab validation is claimed.
- HTTP Status Code Overview - Internet Information Services | Microsoft Learn
- Troubleshooting 502 errors in ARR - Internet Information Services | Microsoft Learn
- Failure Settings for an Application Pool <failure> | Microsoft Learn
Additional revision sources: