IIS (Internet Information Services) · Sites & App Pools

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.

Intermediate 5 min Lesson 9 of 33Covers IIS 10 on Windows Server 2019/2022/2025 and Windows 10/11.
Before you start:Application Pools
0/33 in IIS
On this page · 5 min · Intermediate

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#

PowerShellRecycle at 03:00 only, plus a memory safety net Illustrative
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
Expected output
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#

  1. Setting time to zero disables the 29-hour interval.
  2. A schedule entry recycles daily at 03:00.
  3. privateMemory recycles if the process exceeds ~1.5 GB.
  4. 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#

Storing sessions in process memory

Every recycle logs users out. Use a distributed session store.

Data Protection keys not persisted

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
C# Illustrative
builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(@"C:\keys\shop"))
    .SetApplicationName("Shop");

Mini quiz#

Application Pool Recycling quizMultiple choice Question 1 of 1

What is lost when an app pool recycles?

Score so far: 0/0

Want more? Practise all IIS MCQs · IIS interview questions

My notes#

Saved in this browser.

Progress is saved in this browser. Sign in to sync.