Summit 7 Team Blogs

Recycling SharePoint’s OWSTIMER (Net Stop / Start SPTimerV4)

As SharePoint Admins, we seem to do this rather haphazardly particularly when installing solutions involving GAC deployments. We seem to forget (or ignore) that this abrupt stoppage crashes running timer jobs.

Starting with SP2010, a timer job runs by default once daily at 6:00 AM to recycle the timer service. The primary work of the Timer Service Recycle job is to restart the Timer Service by calling on the Administration Service to do so. However, the timer job goes through a “Warning” period (default is 10 minutes) where no non-critical timer jobs are started and all pausable jobs are paused. The two internal jobs, the Timer Locks Refresh job, the Config Refresh job, and all one-time jobs are the only jobs allowed to begin execution during the warning period except that even these will not start during the final 30 seconds.

This is a cleaner, safer way to recycle the service.

However, executing the timer job from Central Admin > Monitoring  > Review Job Definitions > Timer Service Recycle or with the PowerShell  Get-sptimerjob job-timer-recycle | start-sptimerjob , the recycle completion would normally take up to 11 minutes.

You may prefer to (temporarily) adjust the RecycleWarningMinutes to a shorter period using the PowerShell shown below. (I included some extra informational steps so you could see what was happening.)

PS C:\> $timer  = (get-spfarm).timerservice
PS C:\> $timer
TypeName                    : Microsoft SharePoint Foundation Timer
InitialSweepSchedule        : every 5 minutes between 0 and 59
SweepSchedule               : hourly between 0 and 59
LockRefreshSchedule         : every 15 minutes at 0
LockTimeout                 : 20
RecycleWarningMinutes       : 10
ProcessIdentity             : SPProcessIdentity
Instances                   : {}
Applications                : {}
Required                    : False
JobDefinitions              : {job-diagnostics-blocking-query-provider, job-diagnostics-sql-dmv-provider,
                              job-diagnostics-sql-deadlock-provider, job-password-management...}
RunningJobs                 : {}
JobHistoryEntries           : {, , , ...}
CanUpgrade                  : True
IsBackwardsCompatible       : True
NeedsUpgradeIncludeChildren : False
NeedsUpgrade                : False
UpgradeContext              : Microsoft.SharePoint.Upgrade.SPUpgradeContext
Name                        : SPTimerV4
DisplayName                 : SPTimerV4
Id                          : 7c4d632d-6912-41de-84df-c532b07c803d
Status                      : Online
Parent                      : SPFarm Name=SP2013_Config
Version                     : 2519
Properties                  : {}
Farm                        : SPFarm Name=SP2013_Config
UpgradedPersistedProperties : {}

PS C:\> $timer.recyclewarningminutes
PS C:\> $timer.recyclewarningminutes = 3
PS C:\> $timer.update()
PS C:\> $timer.recyclewarningminutes
PS C:\> Get-sptimerjob job-timer-recycle | start-sptimerjob


In the ULS logs you will see entries like these:

Even on my small single member demo farm there were 67 timer jobs that were paused that would have crashed had I used NET STOP SPTIMERV4 command.

I also saw over 60 ULS log entries like this one for the next 3 minutes:

Recycle warning in progress, job will not be run immediately. Title:Upgrade site collections job, Id:{7A7AFCFC-C011-4510-8FDC-5C0A4ED35C04}

These were followed by lots more “Pausing timer job” entries before finally the timer service stopped and started again 30 milliseconds later. Then the timer service loaded all the job definitions and was starting jobs as scheduled again.

Making these changes and recycling the OWSTIMER service in this manner may take longer but should not disrupt timer jobs that are currently running.

You will probably want to reset the recyclewarningminutes back to the default of 10 when finished.

Another command switch that we miss with all the recycling is IISRESET /NoForce so that web service jobs and running event receivers are not crashed. See Josh Gavant’s blog post at for more detailed information.

This blog has been cross-posted to Life with Semaphore blogs at



The sample scripts are not supported under any Summit 7 Systems standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Summit 7 Systems further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Summit 7 Systems, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Summit 7 Systems has been advised of the possibility of such damages.