1. Record the affected hostname, URL and failure time. Check whether other websites on the server still work.
2. In IIS Manager, select the website and identify the application pool it uses. Open Application Pools and inspect that pool's status.
3. Review the request's status and substatus in the IIS logs. A 503.0 can indicate an unavailable application pool; other substatuses require their own interpretation.
4. If the request is absent from the site log, inspect the HTTPERR logs, normally under C:\Windows\System32\LogFiles\HTTPERR. Record the reason field and matching timestamp.
5. Check System and Application events for Windows Process Activation Service, worker-process crashes, identity failures or missing application dependencies.
6. Compare the pool identity, password changes for custom accounts, filesystem permissions, runtime requirements and recent deployment changes with the last working state.

IIS can take an application pool out of service after repeated worker-process failures. Treat that as evidence of a recurring problem. Keep rapid-fail protection in place while you identify the crash or startup cause; disabling it can create a continuous failure loop.

After correcting the identified problem, start the affected pool and test a controlled request. If it stops again, capture the new events and escalate with the application version and failing component. Avoid recycling unrelated sites or restarting the entire server without assessing their workloads.

A running pool does not rule out every 503 cause. Correlate the specific substatus or HTTPERR reason with request limits, queues and resource pressure. Increase a limit only after confirming that the application and server can handle the intended load.

Open an elevated PowerShell session on the IIS server. AppCmd is installed with the IIS management components. Replace ExamplePool with the application pool used by the failing website. These commands list state and existing worker processes.

& "$env:windir\System32\inetsrv\appcmd.exe" list apppool "ExamplePool"
& "$env:windir\System32\inetsrv\appcmd.exe" list wp

Read the result: A stopped pool helps explain some HTTP 503 cases, but it does not explain why the pool stopped. Check the matching Windows events for rapid-fail protection, identity logon failures, configuration errors or startup crashes. An on-demand pool may have no worker process before its first request.

Confirm the website-to-application-pool mapping before making a change. Do not repeatedly disable rapid-fail protection or recycle every pool on a shared server. Correct the specific cause, start only the intended pool through the approved workflow and retest the original URL.

• Diagnosing an IIS HTTP 500 error
• Enabling and using IIS request logs
• Choosing and securing an IIS application-pool identity
• Finding a Windows Server CPU or memory bottleneck

• Microsoft: troubleshoot IIS HTTP errors
• Microsoft: IIS HTTP status codes
• Microsoft: IIS rapid-fail protection
• Microsoft: IIS application pool identities

• Microsoft: AppCmd IIS administration