BROKER_RECEIVE_WAITFOR is recorded when a session has issued a WAITFOR (RECEIVE ...) against a Service Broker queue and is waiting for a message to arrive. Queue readers are designed to block until there is work, so on a quiet conversation this wait can legitimately run for hours.
If you use Service Broker (or features built on it, like event notifications or some queue-based application designs), this is the sound of readers standing by.
Is It a Problem?
No; an empty queue with a patient reader is the intended resting state, and this wait is filtered as benign. Its total mostly measures how quiet your queues are and how many readers wait on them.
The performance questions that matter for Service Broker are elsewhere: whether messages are flowing (transmission queues backing up), whether activation keeps up with arrival rates, and whether conversations are being closed properly (leaked conversations bloat things over time). None of those reads through this wait.
Common Causes
- Queue reader procedures blocked on
RECEIVE WAITFORwith no messages arriving. - Application designs with standing readers on rarely used queues.
What To Do
- Filter it out of wait analysis; our
Get-WaitStatisticsscript does by default. - For actual Broker health: check
sys.transmission_queuefor stuck messages, activation procedure errors in the error log, and conversation counts for leaks. - Leave the readers blocking; polling instead of blocking would be strictly worse.
How To See It
Rank waits with Get-WaitStatistics, where it is filtered. Its presence documents that Service Broker readers exist, nothing more.
BROKER_RECEIVE_WAITFOR is background noise on a healthy instance. If you are chasing a real problem, start with the waits that actually cost you time.
- The waits that usually matter, ranked, with what each one is telling you.
- Performance & Troubleshooting, the scripts and guides for this part of the stack.
Leave a Reply