XE_TIMER_EVENT is recorded by a thread waiting for an Extended Events dispatch timer to expire. Event sessions with asynchronous targets buffer events in memory and hand them to the target either when a buffer fills or when the session’s MAX_DISPATCH_LATENCY (30 seconds by default) elapses; this wait is the timer ticking toward that latency deadline.
Since the system_health session runs on every instance, every instance accumulates this wait continuously.
Is It a Problem?
No. It is a timer measuring its own countdown, one of the standard benign waits, and its total scales with uptime and the number of event sessions rather than any performance factor. There is no threshold at which it becomes actionable.
Genuine Extended Events overhead questions are about the sessions themselves: which events they capture, how hot those events fire, and whether targets keep up (XE_DISPATCHER_WAIT territory), none of which reads through this timer.
Common Causes
- system_health and any other event sessions with asynchronous targets existing.
- More sessions, more timers, bigger totals; still meaningless.
What To Do
- Filter it out; our
Get-WaitStatisticsscript excludes it by default. - For real XE overhead concerns, review each session’s event list and predicates, and prefer tight filters on high-frequency events.
- Change nothing based on this wait.
How To See It
Rank waits with Get-WaitStatistics; it is filtered as noise. In raw output it confirms only that event sessions are running.
Part of the SQL Server Wait Types Library.
Related deep dive: ASYNC_NETWORK_IO Wait Type.
Leave a Reply