HTTP Error 503 — The Application Pool Has Been Stopped (IIS)

What’s actually happening

Every request to the site returns 503 and the page is IIS's bare "Service Unavailable" message, no application error, no stack trace, because the app never ran. Open IIS Manager and the Application Pool shows Stopped. The usual trigger is rapid-fail protection: if the worker process (w3wp.exe) crashes 5 times within 5 minutes (the defaults), WAS disables the whole pool to stop burning CPU spawning processes that immediately die. The other common trigger is a bad pool identity, the password on the service account changed and the pool can't start under it.

Common causes

• Rapid-fail protection tripped: 5 w3wp.exe crashes in 5 minutes disabled the pool (Windows System log, Source = WAS, around event 5002 'rapid fail protection' / 5057).
• The Application Pool identity has a stale or expired password, so the pool can't launch its worker (event 5057 / 5059, error 'invalid credentials').
• An unhandled exception or bad dependency in app startup (missing DLL, wrong .NET CLR version, broken web.config) crashing the worker on every spawn.
• The .NET CLR version configured on the pool doesn't match what the app targets (e.g. app needs No Managed Code / .NET Core but the pool is set to v4.0).
• Resource limits, a CPU or private-memory limit on the pool recycling/killing the worker faster than it can serve requests.

How to fix it

1. Read the WAS events in the System log firstOpen Event Viewer, Windows Logs, System, filter Source = WAS. The 5002/5057/5059 entries tell you whether it was rapid-fail (crashes) or an identity/credential failure. This decides everything else, don't just restart blind.
2. If it's crashes, find the real exceptionSwitch to the Application log and look for .NET Runtime / Application Error entries from w3wp.exe at the crash times. That's the actual bug, missing assembly, config error, startup throw. Fix that before restarting, or the pool will trip again in 5 minutes.
3. If it's the identity, reset the pool credentialsIn IIS Manager, Application Pools, Advanced Settings, Identity. Re-enter the service-account password (or switch to ApplicationPoolIdentity if a domain account isn't required). Bad passwords are the #1 cause after a scheduled AD password rotation.
4. Confirm the pool's CLR / pipeline matches the appAdvanced Settings: a .NET Framework app needs CLR v4.0; an ASP.NET Core / out-of-process app needs No Managed Code. A mismatch crashes the worker instantly. Set it correctly, then start the pool.
5. Start the pool and watch it stay upRight-click the pool, Start. Hit the site and refresh the pool view, if it flips back to Stopped, the underlying crash isn't fixed, return to fix #2. Once it holds, raise the rapid-fail threshold only if the crashes are genuinely transient, never as a way to mask a real fault.