On IIS, a 503 Service Unavailable almost always means one thing: the application pool behind the site is stopped. IIS keeps sites and their worker processes separate, and when a pool stops — or crashes repeatedly and gets disabled — every request to its sites returns 503.
1. Check the app pool state
Import-Module WebAdministration Get-IISAppPool # lists every pool + State: Started / Stopped Get-WebAppPoolState -Name <AppPoolName>
A Stopped pool is your answer. If it's Started but still 503ing, the worker process is crashing on startup — go to the event log.
2. Why did it stop? Rapid-fail protection
IIS has a safety feature — rapid-fail protection — that disables a pool if its worker process crashes too many times in a short window (default 5 in 5 minutes). So a stopped pool usually means the app crashed repeatedly. The System and Application event logs (WAS and .NET Runtime sources) record the crashes and the shutdown reason.
3. Start it — and fix the crash
Restart to restore service now — substitute the name of the pool that's actually stopped (from step 1) for <AppPoolName>:
Start-WebAppPool -Name "<AppPoolName>" # or recycle a running-but-unhealthy pool: Restart-WebAppPool -Name "<AppPoolName>"
But starting a pool whose app still crashes just trips rapid-fail protection again in minutes. Use the event-log stack trace to fix the underlying crash — a bad config, a missing dependency, an unhandled exception on startup.
4. Check identity and bindings too
If the pool won't stay started, confirm the pool identity has permission to the site folder and that the .NET CLR version matches the app. A mismatched runtime or a permission error surfaces as a worker that dies instantly.
Practise Windows incidents
Stopped IIS app pools are among the Windows Server incidents in the simulator. Work them in a full incident response shift.