HADR_NOTIFICATION_DEQUEUE is recorded by the background task that processes Windows Server Failover Clustering notifications while it waits for the next notification to arrive. Availability Groups need to hear about cluster events (node changes, resource moves, quorum shifts) the moment they happen, so a dedicated listener sits permanently on that queue.
A listener with nothing to hear is a healthy cluster, and this wait is that listener’s idle time.
Is It a Problem?
No. It is expected, continuous, and benign on any AG-enabled instance, accumulating roughly with uptime. Big totals mean the cluster has been quiet, which is exactly what you want. It has never been a contention point, and no AG performance question is answered through it.
If cluster events are actually flooding in (the opposite condition), you would be investigating the cluster log and AG state changes directly, not this wait.
Common Causes
- Normal AG operation with a quiet, stable cluster.
- Long uptime letting the listener’s idle time accumulate.
What To Do
- Filter it out of wait statistics analysis with the other AG background waits.
- For cluster-event trouble (failovers, lease timeouts), use the cluster log, Windows event logs, and AG state DMVs; the notification listener’s wait time adds nothing.
How To See It
Rank waits with Get-WaitStatistics; it is filtered as noise there. In raw output on AG servers, expect it and move on.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply