HADR_WORK_QUEUE is recorded by Availability Group background worker threads while they sit waiting for new work to appear in the AG work queue. AGs keep a pool of ready workers for replication tasks; a worker with nothing to do parks here until something is assigned.
Idle workers waiting for work is the normal, healthy state of that pool.
Is It a Problem?
No. This is one of the textbook benign waits. On any instance hosting Availability Groups it accumulates around the clock and will often appear near the top of an unfiltered wait list purely because the workers are always there and mostly idle. High HADR_WORK_QUEUE numbers say nothing about AG health, positive or negative.
There is no threshold at which this wait becomes actionable. If you are diagnosing an AG issue, this is noise in the way of the real signals.
Common Causes
- Normal AG operation with spare worker capacity.
- Quiet periods where little log is being generated or redone.
- More AG worker threads available than the current replication volume needs.
What To Do
- Filter it out of wait statistics analysis. Our
Get-WaitStatisticsscript excludes it by default, precisely so real waits surface. - For genuine AG performance questions, go to the replica DMVs:
sys.dm_hadr_database_replica_statesfor send and redo queues, and waits likeHADR_SYNC_COMMITfor commit latency. - Do not tune, reconfigure, or restart anything on the basis of this wait. There is nothing to fix.
How To See It
Rank waits with Get-WaitStatistics; with the benign filter in place you should rarely see this one at all. If you query sys.dm_os_wait_stats raw on an AG server, expect it, and read past it.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply