When you setup a site on IIS it defaults the worker process to recycle every 1740 minutes (29 hours). Why an odd number like 29 hours and not, for example, 24 or 48 hours?


2 Answers 2


At Tech Ed 2003, the presenter was asked this question, and the answer was that they wanted an irregular cycle to prevent it from occurring on a daily boundary (e.g. to distinguish from other daily tasks scheduled on the server / domain).

The site here(Link dead) speculated:

... (29 is the) first prime after 24, allowing it to have the least chance occurring in a regular pattern with any other server process; easing the investigation into problems

Another site appears to confirm this :

(Wade Hilmo) suggested 29 hours for the simple reason that it’s the smallest prime number over 24. He wanted a staggered and non-repeating pattern that doesn’t occur more frequently than once per day

  • Interesting. Personally I think that having something recur at the same time each day would make it easier to track if the worker process recycle was causing other issues. e.g. tracking down an issue that happens approximately every day is tough but it's easier if it happens at 7pm every day because you can search the system for events that happen at that time. I know that you can set IIS to recycle whenever you want or not at all but most leave it at its default. Thanks for the answer!
    – Guy
    Jan 11, 2012 at 6:20

OK, this was bugging me, so I dug around and finally found this posting from a guy who apparently was on the IIS team:

The reason that IIS6 recycles every 29 hours by default (and we had a reason

The reason that IIS6 recycles every 29 hours by default (and we had a reason for choosing 29 hours as the default value) is because more likely than not, the web application running on it is unreliable and literally needs to restart frequently.

Thus, IIS6 is built around the premise (admitedly cynical) that the user's web application will not run for more than 24 contiguous hours, features are planned accordingly, and defaults chosen. Worker processes recycle every 29 hours, process startup and shutdown are monitored, the process is constantly pinged to make sure it is running, the process handle is tracked and signaled when it terminates unexpectedly, etc etc.

Realizing that recycling is a normal part of operations, IIS6 also makes sure to isolate such recycling from the end user -- the end user's TCP connection never terminates during a recycle, due to some kernel-mode magic. Combined with user-mode application which stores session-state out-of-process (like ASP.Net Session State Service), one is virtually guaranteed reliable uptime with no user-visible data loss, even if the web application crashes after processing every single user request.

This is about as good as IIS6 can make it -- given an unreliable web application, make it appear reliable to the end-user, and do it without requiring any fixes of the unreliable web application.

Of course, not all unreliable application can be made to appear reliable -- if so, then we are all out of jobs! -- but IIS6 sure tries a whole lot more to be resiliant.

In your case, it just happens that the resiliancy has a side effect on non-persisted user state, but it can be easily adjusted.

Assuming your web application never has a problem and stays with in- process session state, you will want to change these defaults: 1. Turn off the 29 hour periodic recycling 2. Turn off the 20 minute idle timeout

This will prevent unexpected loss of session state.

Of course, if you ever use an application with out-of-process session state, you can leave everything as the defaults and never notice a difference in functionality nor reliability.

  • 1
    I feel dumb asking this but if IIS assumes the web app does not make it to 24 hrs, how come 29 was a good choice? Shouldn't they have picked a number below 24? Where am I wrong in interpreting this explanation?
    – Alpha
    Jan 12, 2012 at 23:33
  • Perhaps there is no "best" answer for the default value, and the person administering the website should make a deliberate decision based on the app and the system.
    – DOK
    Jan 13, 2012 at 14:09
  • @Alpha - I agree - that doesn't make sense - it should default to 22 or 23 hours or at least something lower than 24.
    – Guy
    May 9, 2012 at 5:15
  • [citation needed]
    – piers7
    Mar 11, 2013 at 0:48
  • I'm getting a strange compile error on parts of the website every morning that can only be fixed with a recycle. My guess is the Idle Timeout triggers overnight due to low load, and for some reason, when it starts up again, the compile error is back. Thanks for the lead, I'll follow this path to fixing my issue...
    – sonjz
    Jun 16, 2014 at 16:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .