Why this problem matters
Wait statistics show where SQL Server workers spend time, but they are not a standalone error list. Values accumulated since startup can mix a recent issue with older activity.
How to diagnose it
Evaluate total time, task count, and signal wait together. Account for server uptime and focus on deltas between successive samples.
The query reads cumulative wait counters and SQL Server start time. It does not clear waits, and a single sample does not show the recent rate.
SELECT TOP (20)
wait_type,
waiting_tasks_count,
wait_time_ms,
signal_wait_time_ms,
wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE waiting_tasks_count > 0
ORDER BY wait_time_ms DESC;
SELECT sqlserver_start_time
FROM sys.dm_os_sys_info;A safe solution approach
First correlate the dominant wait category with evidence from queries, storage, CPU, or concurrency. Do not change configuration solely to reduce a named wait.
Why continuous monitoring matters
Cumulative counters reset at restart and vary across workload periods. moon can capture meaningful trends through regular sampling and route alerts through Slack, PagerDuty, or webhooks.
Frequently asked questions
Is the highest wait type always the root cause? Should wait counters be cleared regularly?
No, some high waits reflect normal background behavior or old activity. Collecting timestamped delta samples is a safer baseline than regularly clearing counters.
How does moon help with this problem?
moon continuously observes SQL Server, PostgreSQL, and MongoDB signals, helping teams evaluate the problem as a trend instead of relying on a one-time check.