IIS App Pools: Recycling, Identities, and Crash Isolation

Every IIS site runs inside a worker process owned by an application pool, and the pool’s configuration decides how much damage one broken site can do to its neighbors. A misconfigured pool is the classic cause of 503 Service Unavailable errors, unexplained memory growth, and 3 a.m. restarts. The good news is that pool settings are a small set of knobs you can reason about. If you are still choosing where to host, compare Windows VPS plans on our provider comparison table — pool tuning matters most when several sites share one server.

Recycling Triggers and What They Reset

Recycling restarts the worker process: all in-flight requests are terminated (unless overlapping recycling is enabled), memory is released, and the app starts from a clean state. The defaults exist because leaked memory is normal; recycling is the safety net. The triggers, set per pool, are:

Setting	Default	What it does
Regular time interval	1740 minutes (29 h)	Recycles on a fixed clock
Specific times	None	Recycles at scheduled times, e.g. 03:00
Request limit	0 (unlimited)	Recycles after N requests
Virtual memory limit	0	Recycles when the worker’s virtual memory exceeds the MB value
Private memory limit	0	Recycles when the worker’s private bytes exceed the MB value
Idle timeout	20 minutes	Shuts down an idle worker to free RAM

Set memory limits slightly above the app’s steady state, not at the first sign of a spike. A limit set too low turns every burst of traffic into a recycling cascade — more 503s, not fewer.

Overlapping Recycling Removes the Blip

By default IIS starts the new worker, waits for it to be healthy, and only then terminates the old one — this is “overlapping recycling,” controlled by disallowOverlappingRotation. Keep it enabled for any site that cannot tolerate dropped requests. In applicationHost.config:

<add name="myapp" autoStart="true">
  <recycling disallowOverlappingRotation="false">
    <periodicRestart time="00:00:00">
      <schedule><clear /><add value="03:00:00" /></schedule>
    </periodicRestart>
  </recycling>
</add>

This configuration disables the 29-hour timer and recycles daily at 03:00 with overlap, which is a good pattern for line-of-business apps that leak slowly.

Identities: Who the Worker Runs As

The default ApplicationPoolIdentity is a per-pool virtual account. It has no password to rotate, and you grant it access with icacls using the IIS AppPool\<poolname> syntax. Do not switch to NetworkService or a domain account out of habit — the virtual account is the least-privilege default. The one common exception is SQL Server authentication: apps that connect to SQL with integrated security need the pool identity granted a login in SQL, which works fine with the virtual account too. If an app hardcodes a SQL username and password instead, keep the pool identity anyway; the credentials live in the connection string, not in the process.

Crash Isolation: Rapid-Fail Protection

Rapid-Fail Protection counts worker crashes within a time window (default: 5 crashes in 5 minutes) and, when exceeded, stops the pool and returns 503 to every request until an administrator restarts it. That sounds harsh, but it is the mechanism that keeps a crashing app from hammering the server in a restart loop. In practice, if you see rapid-fail 503s, the app is broken — fix the code, do not raise the threshold. The worker-process ping settings (health monitoring) are separate: IIS pings the worker every 30 seconds and recycles it if there is no response, which catches hangs that do not produce crashes.

Troubleshooting 503s in the Event Log

When a pool stops, the story is in the System event log under source Microsoft-Windows-WAS. Event 5002 is a pool stop, 5009/5010 cover worker process crashes, and 5011 is the rapid-fail shutdown. The text of the event names the reason — memory limit exceeded, crash count, or manual stop. Recycle events come from source Microsoft-Windows-IIS-W3SVC-WP. Read both sources before touching settings; the log almost always identifies the trigger, and the fix is usually one setting, not three. For a deeper trace on a crash that produces no useful event text, enable Failed Request Tracing on the site and reproduce the request — the trace shows exactly where the worker died.

Application pools are the cheapest isolation you get on a single Windows VPS — treat them like free containers. For the rest of the setup checklist, walk the Windows VPS feature overview, and if you need a box with enough RAM to keep several pools healthy, see the latest Windows VPS plans.