Every IIS application pool recycles itself on a schedule — by default every 1,740 minutes (29 hours) — but the default is rarely the right answer for your workload. Recycling is IIS’s way of releasing leaked memory, closing stale connections, and clearing corrupted state, and it happens far more often than most administrators realize. This article explains each recycling condition, how to configure them through IIS Manager and appcmd, and how to deploy application updates with zero dropped requests using overlapping recycling and app_offline.htm. These techniques apply to any Windows Server running IIS, including the Windows VPS hosting setups covered elsewhere on this site.
What actually triggers a recycle
IIS recycles a worker process (w3wp.exe) when any of these conditions are met:
- Time interval: the pool has run for the configured number of minutes (default 1,740).
- Specific times: a fixed daily schedule, e.g. 03:00.
- Virtual memory limit: the process exceeds a configured MB threshold — the classic fix for 32-bit worker processes that balloon over time.
- Private memory limit: same idea, but only the process’s private bytes count.
- Requests limit: the pool has served N requests (useful for long-running, request-heavy apps).
- Configuration change: editing applicationHost.config or the pool’s settings triggers a recycle so changes take effect.
Each condition can be combined. The default 29-hour interval is a compromise tuned for nothing in particular; most production teams set one primary condition and disable the rest so recycling behavior is predictable.
Configure recycling in IIS Manager
In IIS Manager, select Application Pools → your pool → Advanced Settings. Under Recycling, three settings matter:
- Regular Time Interval (minutes): set to 0 to disable time-based recycling.
- Specific Times: add e.g. 03:00 for a nightly recycle during low traffic.
- Virtual Memory Limit (KB) / Private Memory Limit (KB): set to 0 to disable, or a sane ceiling such as 1,048,576 KB (1 GB) for a small app.
From PowerShell, the equivalent using the WebAdministration module is:
Import-Module WebAdministration
Set-ItemProperty "IIS:\AppPools\MyApp" -Name recycling.periodicRestart.time -Value "00:00:00"
Set-ItemProperty "IIS:\AppPools\MyApp" -Name recycling.periodicRestart.schedule -Value @("03:00:00")
Set-ItemProperty "IIS:\AppPools\MyApp" -Name recycling.periodicRestart.privateMemory -Value 1048576Or with appcmd, which works on Server Core:
appcmd set apppool "MyApp" /recycling.periodicRestart.time:00:00:00
appcmd set apppool "MyApp" /+recycling.periodicRestart.schedule.[value='03:00:00']
appcmd set apppool "MyApp" /recycling.periodicRestart.privateMemory:1048576Recycling conditions: a reference table
| Condition | Setting | Best for | Recommended value |
|---|---|---|---|
| Time interval | Regular Time Interval | Legacy apps that leak slowly | 1,440 (24 h) or 0 if using Specific Times |
| Fixed schedule | Specific Times | Predictable low-traffic windows | 03:00 daily |
| Virtual memory | Virtual Memory Limit | 32-bit pools with runaway memory | ~1.5× observed peak |
| Private memory | Private Memory Limit | Most managed .NET apps | ~1.5× observed peak, min 1 GB |
| Requests served | Request Limit | High-traffic stateless apps | Often left disabled |
To find a pool’s observed peak memory, run Get-Process w3wp -ErrorAction SilentlyContinue | Sort WorkingSet64 -Descending | Select -First 5 during peak hours for a few days, then set the limit to 1.5× that value. A limit that is too tight causes constant recycling and cold-start latency; too loose, and you are back to the leak you were trying to contain.
Zero-downtime deployments with overlapping recycling
The default recycle kills the old worker process and starts a new one. Between those two moments, incoming requests either queue or fail — a visible blip for users. Two settings fix this:
- Disallow Overlapping Rotation = False (default): the new worker process starts and warms up before the old one is terminated, so no request is ever left without a listener. Do not disable this unless you have a hard reason.
- Recycle on Configuration Change = True: the pool recycles when applicationHost.config changes, so your
web.configedits take effect without a manual recycle.
For application code deployments (new DLLs, static assets), the cleanest pattern is:
- Drop an empty
app_offline.htmfile into the site root. IIS immediately stops the app pool and serves the file for all requests. - Copy your new files over the old ones.
- Delete
app_offline.htm. IIS restarts the pool and serves the new version.
This is the pattern behind most CI/CD pipelines that deploy to IIS, and it guarantees users see a maintenance page at worst — never a 503 from a half-copied deployment. If you want the full CI/CD picture, the build-agent article on this blog covers the server side of that pipeline.
Warm-up: the hidden cost of every recycle
Every recycle clears the JIT cache, the ASP.NET view state cache, and any in-memory caches your app built since startup. A .NET application can take 10–60 seconds to reach full speed again after a recycle, and during that window your users see slow page loads. Mitigations, in order of effort:
- Application Initialization module: configure a warm-up page so IIS sends a request to the app immediately after startup. With
appcmd set config "MySite" /section:system.applicationHost/applicationPools /+[name='MyApp'].processModel.startupTimeLimit:120and the module’sdoAppInitAfterRestartsetting, the pool pre-loads before serving traffic. - Schedule recycles for low traffic: a 03:00 recycle on a global audience site is far less painful than a noon one.
- Watch the event log: recycle events (Event IDs 5074–5076 from WAS, plus 1000/1002 from the .NET Runtime on crash) tell you whether recycles are happening on schedule or being forced by memory limits.
What recycling will not fix
Recycling is a bandage, not a cure. If your pool hits its memory limit every hour, the underlying leak is in unmanaged code, a misconfigured cache, or a driver — recycling just hides the symptom while costing you warm-up time. Track the pool’s memory across a week; if the pattern is “climb, recycle, climb, recycle,” fix the leak instead of tuning the limit. Likewise, connection-pool exhaustion in SQL Server is not solved by recycling; the app pool restart actually makes it worse by tearing down healthy pooled connections.
A deliberate recycling policy — one primary condition, a fixed schedule, overlapping rotation enabled, and a warm-up page — keeps IIS predictable and your deployments boring. That predictability is exactly what you want from the web server in front of your application. If you are setting up IIS on a fresh server, our Windows VPS plans come with Server 2022 or 2025 images where all of these settings are one console away.
