SQL Server Wait Statistics Baseline

Interpret cumulative wait statistics in uptime context. Use moon to track changes in the production wait profile over time.

2026-09-02 · 2 min read

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.