BROKER_RECEIVE_WAITFOR Wait Type Explained

This wait accumulates in sys.dm_os_wait_stats when Service Broker applications use the RECEIVE WAITFOR syntax to monitor message queues. The WAITFOR clause puts the receiving thread into a controlled sleep state, during which SQL Server logs BROKER_RECEIVE_WAITFOR waits. The wait occurs at the scheduler level as the thread voluntarily yields CPU while monitoring for queue activity.

Service Broker's internal message dispatcher generates these waits during normal operation. When no messages exist in monitored queues, receiving sessions enter this wait state rather than consuming CPU cycles in tight polling loops. The wait clears immediately when messages arrive or when the WAITFOR timeout expires.

SQL Server 2016 through 2025 exhibit identical behavior for this wait type. The Service Broker architecture remains fundamentally unchanged across these versions, with the same internal queue monitoring mechanisms producing these expected waits.

Applications using Service Broker for asynchronous messaging, database mirroring endpoints (legacy), and Always On availability groups can generate BROKER_RECEIVE_WAITFOR waits during normal operations. These waits indicate healthy message queue monitoring, not resource contention or performance degradation.

Confirm BROKER_RECEIVE_WAITFOR presence and verify it represents idle waiting, not active blocking:

-- Show BROKER_RECEIVE_WAITFOR statistics
SELECT 
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    max_wait_time_ms,
    signal_wait_time_ms,
    wait_time_ms / NULLIF(waiting_tasks_count, 0) AS avg_wait_ms
FROM sys.dm_os_wait_stats 
WHERE wait_type = 'BROKER_RECEIVE_WAITFOR';

Query actionable waits by filtering benign types including BROKER_RECEIVE_WAITFOR:

-- Wait stats excluding benign waits
WITH FilteredWaits 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 (
        'BROKER_RECEIVE_WAITFOR',
        'BROKER_TASK_STOP',
        'CHECKPOINT_QUEUE',
        'CLR_AUTO_EVENT',
        'DIRTY_PAGE_POLL',
        'DISPATCHER_QUEUE_SEMAPHORE',
        'FT_IFTS_SCHEDULER_IDLE_WAIT',
        'LAZYWRITER_SLEEP',
        'LOGMGR_QUEUE',
        'REQUEST_FOR_DEADLOCK_SEARCH',
        'SLEEP_TASK',
        'SP_SERVER_DIAGNOSTICS_SLEEP',
        'SQLTRACE_BUFFER_FLUSH',
        'XE_DISPATCHER_WAIT',
        'XE_TIMER_EVENT'
    )
)
SELECT TOP 20
    wait_type,
    wait_time_ms,
    waiting_tasks_count,
    wait_time_ms / NULLIF(waiting_tasks_count, 0) AS avg_wait_ms,
    CAST(wait_time_ms * 100.0 / SUM(wait_time_ms) OVER() AS DECIMAL(5,2)) AS wait_pct
FROM FilteredWaits
WHERE wait_time_ms > 1000
ORDER BY wait_time_ms DESC;

No prevention required for BROKER_RECEIVE_WAITFOR waits since they indicate normal Service Broker functionality. Attempting to eliminate these waits would disable legitimate Service Broker message processing. The proper approach involves filtering these waits from performance monitoring rather than preventing their occurrence.

Modern SQL Server monitoring solutions like AutoDBA automatically exclude benign waits from analysis, allowing DBAs to focus on waits that indicate actual performance problems. Manual wait statistics queries should implement similar filtering to avoid chasing false performance issues.