Context
An IIS application pool recycle can be an expected operating event, but customers should not discover it through lost sessions or failed requests. The effect depends on worker overlap, application startup, shutdown deadlines, and where state is stored. Moving a recycle to a quieter hour may reduce visibility while leaving the underlying availability problem unchanged.
Consider an illustrative business portal whose users lose progress around the same time each night. The application pool has a scheduled recycle, and important state lives only in the worker process. The schedule explains when the problem occurs; it does not explain why the application cannot tolerate normal worker replacement.
Identify the actual recycle reason
IIS exposes recycling configuration and event logging controls for several triggers, including schedules, resource conditions, requests, and configuration changes. The recycling settings also include whether another worker may start while the old worker shuts down. Version and effective configuration matter, so inspect the pool and relevant event evidence rather than assuming a default. 1
Record the application pool, worker process IDs, trigger, timestamp, recent deployment or configuration change, and customer impact. A new process ID alone does not tell you whether the event was scheduled, requested by an operator, or caused by another condition.
Separate recycling from crashes and rapid failure
Review Windows event logs, IIS logs, application logs, and process termination evidence. Distinguish a controlled recycle from an application crash, service restart, or another process-management action. These can all produce a new worker while requiring different remediation.
If memory or another resource condition triggers recycling, investigate the growth pattern. A repeated recycle can contain symptoms while a leak or unbounded workload remains. Capture enough diagnostic evidence through the approved process before the next restart removes the state needed for investigation.
Understand overlapping worker behaviour
Starting a new worker before the old one exits can help preserve request handling, but the application must tolerate a period with multiple workers. Review shared files, in-memory locks, singleton assumptions, and background jobs. An application that assumes exactly one process can perform duplicate work or corrupt shared state during overlap.
Do not disable overlap merely because duplicates appeared without reviewing the application contract. That may replace duplicate work with an outage. Conversely, enabling overlap is not automatically safe for software that explicitly cannot support it. Choose the setting with evidence about how this application behaves.
Make startup ready before traffic depends on it
Measure cold startup, configuration loading, dependency connection, and cache warm-up. The new worker may exist before it can serve useful requests. Use the supported application initialization and readiness approach for the deployed stack, and validate the actual public request path.
A warm homepage does not prove every route is initialized. Test a representative authenticated request, database operation, and any important integration. Keep warm-up actions harmless so the initialization process does not create real orders, send messages, or run a scheduled job twice.
Review state that disappears with a process
Inventory session state, temporary uploads, progress tracking, and cached business decisions. Decide which state can be discarded and which needs a shared or durable store. A user should not lose an important business operation merely because a worker is replaced under normal maintenance.
If moving session or workflow state, review serialization, expiry, encryption, and compatibility across old and new releases. A shared store solves only part of the problem. The application still needs a clear contract for concurrent updates and for data created by a worker that exits before returning a response.
Coordinate long requests and background work
Inspect shutdown deadlines and the application's handling of in-flight work. A long export may be interrupted even when normal web requests survive the recycle. Define whether it resumes, restarts safely, or runs in a separate worker architecture with durable job tracking.
Avoid relying on an in-process timer as the sole owner of essential scheduled work without a recovery design. During overlap, two workers may run it; during downtime, neither may run it. Use operation identities and a durable completion record where the business requires reliable execution.
Test a recycle deliberately
In a suitable nonproduction or approved maintenance context, run representative traffic and trigger a controlled recycle. Observe errors, latency, worker overlap, session continuity, and background-job outcomes. Include a long request and a user workflow with unsaved or partially saved work.
Define success from the customer's perspective. A successful event may require no lost committed operations, acceptable transient latency, preserved sessions where promised, and no duplicated scheduled actions. Keep the test result associated with the application and IIS configuration versions used.
Tune the trigger after understanding the effect
Choose schedules and resource thresholds based on measured behaviour and business traffic. Keep event logging useful enough to explain future recycles. A schedule change is reasonable when it supports an understood operating plan, but it should not be presented as a permanent fix for unexplained memory growth or fragile state.
A focused operator exercise: A worker-overlap acceptance exercise
Use a test workflow with a durable operation identity and a long-running harmless request. Trigger a controlled recycle under representative traffic, then observe old and new worker lifetimes, session behaviour, request outcome, and any background timer execution. Verify the application's singleton assumptions remain valid during the overlap.
If an operation is interrupted, demonstrate the documented recovery path without duplicate business effects. Keep the recycle reason and effective startup and shutdown settings in the record. This exercise gives the team a direct comparison between process-management success and application continuity, and reveals whether changing the schedule would merely move the same failure to another time.
Quick diagnostic map
| Evidence | Review | Acceptance boundary |
|---|---|---|
| Recycle trigger | Identify scheduled and resource-driven recycles | Correlate with the incident timeline |
| Worker overlap | Measure simultaneous process demand | Include startup and draining costs |
| Application state | Test in-flight work and session behaviour | Keep critical state outside a disposable worker |
Frequently asked questions
Does overlapping recycling guarantee zero interruption? No. Application initialization, state, shutdown, and shared-work behaviour still determine the outcome.
Clouvenix can review IIS process management and application lifecycle together, helping teams make routine worker replacement predictable and customer-visible failures easier to diagnose.
For a scoped review of this workflow, discuss the relevant Clouvenix engineering service.