We have a scheduled background task hosted inside an IIS application. When its app pool recycles, the new worker process can start before the old one has finished shutting down. That makes me wonder whether both processes can briefly run the same job.
Has anyone dealt with duplicate work during an overlapped recycle? I’m especially interested in what happens to jobs that take longer than the app’s shutdown time limit, and whether the answer changes with the recycle reason.
The job updates shared database records, so I’d rather understand the edge cases before relying on IIS lifecycle events to coordinate it.
Yes, it can—but whether it does depends on how the job is triggered. A recycle does not automatically replay every job. The risk is highest when application startup launches work directly, or when a scheduler treats each app start as a fresh instruction to run it.
For work that must not be duplicated, make the operation safe to retry rather than relying on the IIS lifecycle to provide exactly-once execution. For example, record a job’s completion or use a stable job ID so a second attempt can detect that the work has already been applied. For jobs that must be claimed by only one worker, use a shared coordination mechanism such as a database-backed lease or lock; an in-memory flag cannot coordinate separate processes.
Also check what happens if a worker is stopped partway through a job. A replacement may pick up unfinished work, which is useful for reliability but can repeat side effects unless the job is idempotent. Payment requests, emails, and external API calls deserve particular care: store progress or use the provider’s idempotency key where available.
If the task is important or long-running, a durable job queue or a separate worker service is usually a better fit than starting it as a side effect of an IIS app launch. IIS can recycle web processes; job execution should be designed to survive that without depending on a single process staying alive.
Yes. An overlapped recycle can let the old IIS worker process and its replacement run at the same time. If both processes start the same in-process background job, they can briefly execute it concurrently—or the new process can repeat work the old one already started.
This is more likely when the job starts automatically with the application, runs on a timer, or has no shared record of which work has already been claimed. A static flag or in-memory lock won’t prevent duplication: each worker process has its own memory.
How to make the job safe
Disabling overlapped recycling may reduce the chance of two workers running at once, but it doesn’t provide reliable once-only execution. Application restarts, crashes, deployments, and multiple web-server instances can still cause concurrent or repeated runs.