HADR_LOGCAPTURE_WAIT Wait Type Explained

The Always On log capture thread generates HADR_LOGCAPTURE_WAIT when it has processed all available log records and waits for new transactions to generate additional log activity. This thread runs continuously on primary replicas, scanning the transaction log to identify records that need replication to secondary replicas.

The wait occurs in two scenarios: when the log scan catches up to the log writer (indicating low transaction activity) or when reading log blocks from disk that aren't cached in memory. The log capture process uses a polling mechanism that sleeps briefly when no new log records are available, generating this wait type during the sleep interval.

SQL Server 2016 and later versions optimized the log capture efficiency but the fundamental wait behavior remains unchanged. The wait duration is typically very short (milliseconds) and high wait counts are normal for healthy Always On configurations with low to moderate transaction volumes.

This wait accumulates constantly on primary replicas regardless of workload intensity. During periods of high transaction activity, wait counts may decrease as the log capture thread finds more work available, but the wait never disappears entirely.

Verify HADR_LOGCAPTURE_WAIT presence and confirm it's not indicating performance issues:

-- Check current Always On wait statistics
SELECT 
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    wait_time_ms / waiting_tasks_count AS avg_wait_time_ms,
    signal_wait_time_ms,
    max_wait_time_ms
FROM sys.dm_os_wait_stats 
WHERE wait_type = 'HADR_LOGCAPTURE_WAIT'
AND waiting_tasks_count > 0;

Query to show filtered wait statistics excluding benign waits:

-- Wait stats analysis excluding benign Always On waits
WITH filtered_waits AS (
    SELECT 
        wait_type,
        wait_time_ms,
        waiting_tasks_count,
        signal_wait_time_ms
    FROM sys.dm_os_wait_stats
    WHERE wait_type NOT IN (
        'HADR_LOGCAPTURE_WAIT',
        'HADR_TIMER_TASK',
        'HADR_WORK_QUEUE',
        'HADR_CLUSAPI_CALL',
        'FT_IFTS_SCHEDULER_IDLE_WAIT',
        'XE_TIMER_EVENT',
        'XE_DISPATCHER_WAIT',
        'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP'
    )
    AND wait_time_ms > 0
)
SELECT TOP 20
    wait_type,
    wait_time_ms / 1000.0 AS wait_time_seconds,
    waiting_tasks_count,
    CAST(100.0 * wait_time_ms / SUM(wait_time_ms) OVER() AS DECIMAL(5,2)) AS percentage
FROM filtered_waits
ORDER BY wait_time_ms DESC;

No prevention is needed for HADR_LOGCAPTURE_WAIT as it represents normal Always On Availability Groups operation. Attempting to eliminate this wait would require disabling Always On functionality entirely.

Focus monitoring efforts on actionable wait types that indicate resource contention or configuration problems. Modern monitoring tools like AutoDBA automatically filter benign waits, allowing DBAs to concentrate on waits that actually impact user experience and require intervention.

The presence of HADR_LOGCAPTURE_WAIT confirms that Always On log capture is functioning correctly. Absence of this wait on a primary replica would indicate a more serious problem with the Always On subsystem.