HADR_TIMER_TASK is recorded around the Availability Group timer machinery: threads waiting for access to the list of AG timers, plus the deliberate waits between runs of periodic AG tasks. A task that runs every ten seconds spends roughly ten seconds in this wait between executions, so the wait’s total mostly measures scheduled idleness.
Every AG-enabled instance accumulates it constantly.
Is It a Problem?
No. Like the other AG background waits (HADR_WORK_QUEUE, HADR_FILESTREAM_IOMGR_IOCOMPLETION, HADR_NOTIFICATION_DEQUEUE), it is timer bookkeeping, not a performance signal. It has not been a contention point in practice, and its size tracks uptime and the number of AG databases rather than anything health-related.
Real AG health questions are answered by the replica-state DMVs and the actionable waits (HADR_SYNC_COMMIT, HADR_DATABASE_FLOW_CONTROL), never by this one.
Common Causes
- Normal periodic AG task scheduling on any instance hosting Availability Groups.
- More AG databases meaning more timers ticking.
What To Do
- Filter it out of wait analysis with the rest of the AG background set.
- For AG lag or commit latency, go straight to
sys.dm_hadr_database_replica_statesand the sync/flow-control waits. - Change nothing on the basis of this wait; there is nothing behind it to change.
How To See It
Rank waits with Get-WaitStatistics, where it is treated as noise. Seeing it in raw output confirms only that AGs are configured.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply