Application Pool Recycling
Recycling replaces a worker process with a fresh one. It keeps long-running apps healthy — but can surprise you if you don’t understand it.
On this page · 5 min · Intermediate
On this page
- In simple words
- Learning objectives
- Explanation
- Code example
- Step by step
- Real-world use
- Common mistakes
- Best practices
- Remember this
- Practice exercise
- Mini quiz
- Related topics
- My notes
- Reading time
- 5 min
- Difficulty
- Intermediate
- Updated
- Oct 30, 2026
Related tutorials
In simple words#
Recycling is a shift change. A fresh worker starts, takes new customers, and the tired worker finishes serving current customers and goes home. Anything kept in the old worker’s head (in-memory sessions, cache) leaves with them.
- Regular time interval
- Default 1,740 minutes (29 hours).
- Overlapped recycle
- New process starts before the old one stops.
- Idle time-out
- Default 20 minutes — pool stops when no requests.
Learning objectives#
- Explain why IIS recycles pools
- Configure time, schedule and memory triggers
- Understand overlapped recycling
- Avoid losing state during recycles
Explanation#
Default triggers: every 1,740 minutes (29 hours, deliberately not a round day so recycles drift), and when idle for 20 minutes the process shuts down.
Better: recycle at a quiet specific time (e.g. 03:00) and disable the regular interval. Memory limits (private bytes) recycle leaking apps.
Overlapped recycle (default) starts the new process before stopping the old one, so users rarely notice.
In-memory sessions, MemoryCache and in-process background work are lost. Store sessions in SQL/Redis and share Data Protection keys.
Code example: Recycle at 03:00 only, plus a memory safety net#
Import-Module WebAdministration
$pool = "IIS:\AppPools\ShopPool"
Set-ItemProperty $pool recycling.periodicRestart.time ([TimeSpan]::Zero) # disable 29-hour interval
Clear-ItemProperty $pool -Name recycling.periodicRestart.schedule
New-ItemProperty $pool -Name recycling.periodicRestart.schedule -Value @{ value = '03:00:00' }
Set-ItemProperty $pool recycling.periodicRestart.privateMemory 1500000 # KB ≈ 1.5 GB
Set-ItemProperty $pool recycling.logEventOnRecycle "Time,Schedule,Memory,ConfigChange,OnDemand"
Get-ItemProperty $pool -Name recycling.periodicRestart | Select-Object time, privateMemory
time privateMemory ---- ------------- 00:00:00 1500000 (Each recycle is now logged in Event Viewer → System, source WAS.)
This example is illustrative. Copy or download it and run it in your own environment; the expected output is shown above.
Step-by-step explanation#
- Setting time to zero disables the 29-hour interval.
- A schedule entry recycles daily at 03:00.
- privateMemory recycles if the process exceeds ~1.5 GB.
- Logging records why each recycle happened.
Real-world use case#
Users kept getting logged out at random times; moving sessions to SQL Server and recycling at 03:00 fixed it.
Common mistakes#
Every recycle logs users out. Use a distributed session store.
After a recycle, auth cookies and antiforgery tokens become invalid. Persist keys to a folder or database.
Best practices#
- Recycle at a scheduled quiet time
- Log recycle events
- Keep apps stateless
- Persist Data Protection keys
Remember this#
Default recycle 1,740 min; idle timeout 20 min.
Recycle = memory state is lost.
Overlapped recycle keeps users served.
Practice exercise#
Your task: Persist ASP.NET Core Data Protection keys to a folder so cookies survive recycles.
Show solution
builder.Services.AddDataProtection()
.PersistKeysToFileSystem(new DirectoryInfo(@"C:\keys\shop"))
.SetApplicationName("Shop");
Mini quiz#
What is lost when an app pool recycles?
Want more? Practise all IIS MCQs · IIS interview questions
My notes#
Saved in this browser.