HADR_LOGCAPTURE_WAIT is recorded by the Availability Group log capture thread on the primary while it waits for log records to become available to ship to secondaries. If the capture thread has already sent everything up to the end of the log, it sits in this wait until the workload generates more, or while it reads older log from disk that is no longer in the log cache.
In other words, this is mostly the replication machinery idling because it is caught up.
Is It a Problem?
No. This is an expected wait on any healthy AG primary, and it accumulates constantly, which is exactly why it often floats near the top of raw wait rankings on AG servers. Being caught up is the good outcome; the thread waiting for more work is not a bottleneck.
The one nuance: some of this wait can come from reading older log from disk when a secondary reconnects after an outage and needs catch-up log that has left the cache. That phase is temporary and self-resolving.
Common Causes
- Normal operation: log capture is caught up and waiting for new transactions.
- Quiet databases in the AG generating little log.
- Catch-up reads after a secondary reconnects, where the wait covers disk reads of older log.
What To Do
- Filter it out of wait analysis, the same way you filter other benign background waits. Our
Get-WaitStatisticsscript focuses on actionable waits for exactly this reason. - If you are troubleshooting AG lag, do not start here. Look at
log_send_queue_size,redo_queue_size, and waits likeHADR_SYNC_COMMITandHADR_DATABASE_FLOW_CONTROLinstead. - If this wait’s average duration suddenly drops while flow control rises, that combination, not this wait alone, tells you the pipeline is saturating.
How To See It
Rank it against everything else with Get-WaitStatistics, and expect to consciously ignore it on AG primaries. Its presence confirms replication is running, nothing more.
Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.
Leave a Reply