About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Many business applications run on IIS, Microsoft's web server: customer portals, line-of-business web front ends, reporting sites and web services that a desktop application calls. Two complaints come up again and again. The first person to use the application in the morning waits a long time for the first page. And users are signed out in the middle of the day for no visible reason.
Three default IIS application pool settings are worth checking: an idle worker process can terminate after 20 minutes, a time-based recycle is configured for 29 hours of elapsed process lifetime, and on-demand start waits for a request. These can explain a cold first request or loss of worker-local session data. A sign-out follows only if the application's sign-in depends on that lost state; authentication also needs its own investigation. Check events and the application's design before changing the settings.
Why it matters
When a web application's worker process stops, everything held in its memory goes with it: cached data, loaded code and, for many older ASP.NET applications, users' session data. The next request has to start the process again and, for a large .NET application, that can take from several seconds to over a minute.
For a public website with constant traffic, this rarely shows. For a business application used by 20 staff from 8:30 to 5:30, it shows every day: the process shuts down overnight, and the first user pays for the start-up. If a recycle occurs at 11 am, session data held in the departing worker process is lost. Users may lose unfinished work or be signed out if the application depends on that data; external session stores are different.
How it works
The idle time-out
IIS shuts down a worker process that has had nothing to do for a while. Microsoft's configuration reference describes the idle time-out as how long (in minutes) a worker process should run idle if no new requests are received and the worker process is not processing requests. The default is 20 minutes, and the reference adds: To disable the idle timeout feature, set this value to 00:00:00.
Since IIS 8.5 there is a second choice. Instead of ending the process, IIS can suspend it. Microsoft says you can choose between terminating the process or suspending it by moving it from memory to disk. Suspending a process will likely take less time and consume less memory than terminating it. In IIS Manager this is the Idle Time-out Action setting, with the values Terminate and Suspend.
Periodic recycling
Separately, IIS replaces the worker process on a schedule. The reference for the time-based recycle says the default value is 29:00:00 (29 hours). For a continuously running worker process with no other recycle or shutdown, successive 29-hour lifetimes move the recycle time five hours later on the clock, potentially into working hours. This is elapsed process lifetime, not a persistent wall-clock schedule. Idle termination, a server restart or another recycle trigger starts a new lifetime; a pool that shuts down every night does not necessarily follow that drifting pattern. Use the actual recycle events to establish the cause and timing.
You can instead recycle at fixed times. The periodic restart settings include a schedule element that Specifies the scheduling of periodic restarts of application pools. Microsoft's own configuration sample sets a recycle at 03:00. Recycling can also be triggered by memory use or a request count, both off by default.
Overlapped recycling
By default, IIS starts the new worker process before the old one shuts down, so requests keep being answered during a recycle. The setting that controls this is described as specifying whether the WWW Service should start another worker process to replace the existing worker process while that process is shutting down. The reference adds that it should be set to true if the worker process loads any application code that does not support multiple worker processes. Some older applications hold an exclusive lock on a file or a port and fail when two copies run at once. Those need overlapping turned off, and will have a short outage at each recycle.
What happens to sessions
Overlapped recycling keeps requests flowing, but it does not carry memory across. For ASP.NET applications that keep session data in the worker process, a recycle loses that session data. It can lose unfinished work, and may sign users out if the application relies on that data for sign-in; neither outcome is universal. Microsoft's ASP.NET documentation describes the default mode: InProc mode, which stores session state in memory on the Web server. This is the default. It contrasts this with the separate ASP.NET state service, which ensures that session state is preserved if the Web application is restarted.
The same documentation says SQLServer session mode also preserves session state across an application restart. Ask the vendor or developers which store this application uses. External storage avoids this particular worker-memory loss, but does not establish that authentication cookies or encryption keys are configured correctly. If sign-outs persist, ask them to check authentication and key persistence separately instead of assuming a recycle always invalidates sign-in.
Start mode and Application Initialization
By default, an application pool does not start until someone requests a page. The reference describes the default start mode, OnDemand, as starting the pool when an HTTP request is made for an application that is hosted in the application pool. The alternative, AlwaysRunning, allows an application to load the operating environment before any serving any HTTP requests, which reduces the start-up processing for initial HTTP requests for the application.
Starting the process is only half the job. A .NET application usually does most of its start-up work on the first real request. The Application Initialization feature fixes that by sending a request of its own when the pool starts. Microsoft describes the setting that turns this on for an application: Setting preloadEnabled to "true" tells IIS 8.0 that it sends a "fake" request to the application when the associated application pool starts up. It can also show a placeholder page while the application warms up.
Application Initialization is an optional part of IIS. Microsoft's reference says that To support application initialization on your Web server, you must install the Application Initialization role or feature. Check it is installed before relying on it.
Recycles are logged, if you let them be
IIS can write an event to the System log each time it recycles a pool, with the reason. According to the recycling settings reference, IIS 10 and later log recycles for time, requests, schedule, memory, private memory, an unhealthy ISAPI extension, on-demand recycles and configuration changes by default; earlier versions logged only time and memory reasons. When users complain about being signed out, these events are the first place to look.
What to choose and why
A starting point for an internal business application
| Setting (IIS Manager name) | Default | Starting value for a small business application | Reason |
|---|---|---|---|
| Idle Time-out (minutes) | 20 | 0 (disabled), or Suspend as the action | Avoids the slow first request after lunch and overnight |
| Regular Time Interval (minutes) | 1740 (29 hours) | 0, replaced by a specific time | Stops the recycle drifting into working hours |
| Specific Times | none | One time outside working hours, for example 03:00 | Recycle when nobody is using the application |
| Start Mode | OnDemand | AlwaysRunning | Process is ready after a restart or recycle |
| Preload Enabled (on the site or application) | False | True, with Application Initialization installed | First real request does not pay for start-up |
| Disable Overlapped Recycle | False | False unless the vendor says otherwise | Keeps requests flowing during a recycle |
These values trade memory for responsiveness. A worker process that never idles out keeps its memory all day. On a server with many application pools, check memory use before disabling the idle time-out everywhere.
Do not stop recycling altogether
It is tempting to turn off recycling because it causes problems. A daily recycle at a quiet time is a reasonable guard against slow memory growth in application code. If an application needs to recycle more often than once a day to stay healthy, that is a defect to report to its developers, not a setting to tune around.
Check with the vendor first
Some business application vendors document exact application pool settings, including identity, .NET version, 32-bit mode and recycling. Follow those first. If the vendor's guidance conflicts with this article, the vendor knows how their code behaves.
At a hosting provider
If a provider manages IIS for you, ask whether application pool settings are left at the defaults, who changes them, and whether recycle events are monitored. A provider that applies the same settings to every customer's server may not know your users work 8:30 to 5:30 Australian time.
Risks and limits
- Disabling idle time-out raises memory use. Every pool stays loaded. On a busy shared server that can push other applications into paging.
- AlwaysRunning and preload need the application to start cleanly without a user. If start-up depends on something only a signed-in user provides, it may log errors at each recycle.
- A scheduled recycle still loses worker-local session data. Choosing a quiet time reduces disruption but cannot guarantee nobody is affected. Sign-in loss depends on the application; StateServer or SQLServer session storage survives the application restart. Moving session storage or changing authentication/key handling requires application-specific review.
- Configuration changes can themselves recycle the pool. IIS by default rotates worker processes when the pool's configuration changes. Make changes outside working hours.
- This article does not cover web gardens or ASP.NET Core hosting models, which change some of this behaviour.
- No commands are given. Settings are named as they appear in Microsoft's configuration reference and IIS Manager. Check them on your server before changing them, ideally on a test copy first.
Sources
Opened 14 November 2026.
- Microsoft Learn: Process Model Settings for an Application Pool, updated 2022-04-06.
- Microsoft Learn: Periodic Restart Settings for Application Pool Recycling, updated 2022-03-23.
- Microsoft Learn: Recycling Settings for an Application Pool, updated 2022-04-06.
- Microsoft Learn: Adding Application Pools, updated 2022-04-06.
- Microsoft Learn: IIS 8.0 Application Initialization, updated 2022-04-06.
- Microsoft Learn: Application Initialization, updated 2022-04-06.
- Microsoft Learn (previous versions): Session-State Modes, ASP.NET 4 documentation, updated 2026-11-07.
Related service: Managed support.
Related future topics
- Application pool identities and file permissions for business web applications.
- Finding the cause of a recycle from the System event log.
- Moving ASP.NET session state out of the worker process.
Learning notes
- IIS shuts an idle worker process after 20 minutes by default, so the next user waits for start-up.
- A continuously running worker's 29-hour recycle can drift into working hours; other restarts or idle termination reset that timeline. Check the events.
- A scheduled recycle at a quiet time, plus AlwaysRunning and preload, keeps the application ready.
- Older ASP.NET applications that keep sessions in memory lose them on every recycle.
- Recycle events in the System log show when and why a pool restarted.
This article was originally published on .