HADR_WORK_POOL is recorded when a thread waits for access to the Availability Group work queue object, the concurrency control around AG background workers getting into position to wait for work. It sits one step before its sibling HADR_WORK_QUEUE (workers idle waiting for work); this one is workers coordinating access to the queue itself.
Both are plumbing inside the AG background worker pool.
Is It a Problem?
No; it has not been a contention point, and its amounts stay small next to HADR_WORK_QUEUE‘s always-large idle totals. It carries no signal about replication health, throughput, or failover readiness, and belongs on the AG background filter list with its siblings.
Nothing in AG troubleshooting starts, or ends, at this wait.
Common Causes
- Normal AG background worker pool coordination on any instance hosting Availability Groups.
- More AG databases meaning more worker traffic through the queue object.
What To Do
- Filter it out with the other AG background waits.
- Keep AG diagnosis on the established path: replica-state DMVs for queues and rates,
HADR_SYNC_COMMITand flow control for latency. - No action exists at this wait’s level.
How To See It
Rank waits with Get-WaitStatistics, where it is treated as noise on AG instances.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply