BROKER_EVENTHANDLER is recorded by the per-instance Service Broker primary event handler thread while it waits for something to handle: a Broker timeout event, or Service Broker starting up or shutting down. One thread, always present, almost always waiting.
Its arithmetic gives it away: the cumulative wait time for this type runs roughly equal to the instance’s total uptime.
Is It a Problem?
No. A single permanently parked background thread is not a bottleneck, and this wait carries no information about Service Broker throughput, backlog, or health. It sits on the standard benign filter list, and its main effect in the wild is padding the top of raw sys.dm_os_wait_stats output on long-running instances.
Everything interesting about Service Broker is measured elsewhere: message flow in sys.transmission_queue, activation health, conversation hygiene.
Common Causes
- The instance being up; the event handler thread exists regardless of Broker usage.
What To Do
- Filter it out; our
Get-WaitStatisticsscript excludes it by default. - Use uptime-equality as a sanity check if you ever wonder whether a wait is a permanent background timer; this one is the textbook example.
- Investigate Broker through its queues and DMVs when needed, never through this wait.
How To See It
Rank waits with Get-WaitStatistics, where it is filtered as background noise.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply