Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
WAITFOR is the most literal wait type in the DMV: it records sessions executing a WAITFOR DELAY or WAITFOR TIME statement. The duration is exactly what the T-SQL asked for. Nothing is contended and nothing is slow; somebody’s code chose to sleep.
That makes it user-initiated by definition, and normally filtered out of analysis.
Is It a Problem?
Not as a performance signal. As a code-inventory signal, occasionally: if WAITFOR carries the most accumulated wait time on an instance, something is sleeping a great deal, and it is worth knowing what. The classics are polling loops (WHILE ... WAITFOR DELAY '00:00:05') in queue-processing procedures, retry loops with sleeps, and the occasional debug WAITFOR accidentally left in deployed code.
One genuine caution: a session sleeping inside an open transaction holds its locks while it sleeps, and that can block others. The victim’s wait would show as LCK_M_*, with the sleeper as head blocker.
Common Causes
- Deliberate polling or throttling loops in application and job code.
- Debug delays left behind in deployed procedures.
- Scheduled coordination hacks (
WAITFOR TIME) inside long-running jobs.
What To Do
- Find the sleepers when curious:
sys.dm_exec_requests WHERE wait_type = 'WAITFOR'with the SQL text tells you who and why. - Replace hot polling loops with better patterns where it matters (Service Broker activation, shorter poll intervals only when work exists).
- Make sure nothing sleeps inside an open transaction; that is the one way
WAITFORhurts others.
How To See It
Rank waits with Get-WaitStatistics; it is filtered as user-initiated. Check the live DMV when you want to know who is napping.
Leave a Reply