SOS_WORK_DISPATCHER is recorded by a SQLOS worker thread that has become idle and is waiting to be handed something to do. The wait starts when the thread runs out of work and ends when the dispatcher assigns it a task. It arrived with scheduling improvements in SQL Server 2019 and is ever-present on Azure SQL Database.
An idle thread waiting for work is the healthy resting state of a thread pool, which is all this wait measures.
Is It a Problem?
No. On SQL Server 2019 and later, and especially on Azure SQL Database, it will frequently be the number one wait by total time on an unfiltered ranking, purely because idle workers accumulate it around the clock. It carries no performance signal in either direction and belongs on the benign filter list with LAZYWRITER_SLEEP and friends.
If anything, lots of SOS_WORK_DISPATCHER time means you have spare worker capacity, the opposite of a thread problem.
Common Causes
- Normal operation on SQL Server 2019+, with pooled workers idling between tasks.
- Azure SQL Database, where it is essentially always present at the top of raw wait output.
- Quiet workloads leaving most of the worker pool parked.
What To Do
- Filter it out of wait statistics analysis; our
Get-WaitStatisticsscript treats it as noise. - Do not read it as CPU or scheduler trouble. Genuine worker-thread starvation shows up as
THREADPOOL, the opposite condition, and CPU pressure shows up in signal wait time andSOS_SCHEDULER_YIELD. - If a monitoring tool alarms on it, fix the tool’s filter list rather than the server.
How To See It
Rank waits with Get-WaitStatistics, where it is excluded as background noise. In raw DMV output on modern versions, expect it at the top and read straight past it.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply