SQL Server Wait Stats Cheat Sheet (2026): Top Waits, What They Mean, What to Fix

What wait stats are (and what they are not)

A wait is time SQL Server spends waiting for a resource: CPU scheduling, disk I/O, locks, memory grants, network writes, tempdb pages, parallelism coordination, and more.

Wait stats are powerful because they help you answer one question quickly: “What is SQL Server waiting on the most right now?”

Important: wait stats are not “errors.” A wait is often normal. The goal is to find the wait pattern that matches your symptom (timeouts, slow pages, blocked sessions) and then confirm the root cause with evidence.

The #1 rule: trend beats snapshots

A single snapshot can mislead you. Wait stats accumulate over time and can reflect yesterday’s pain instead of today’s. What works in real operations is simple:

• Capture baseline (now)
• Capture again (5–15 minutes later during the symptom)
• Analyze the delta (what increased the most)

This is why wait stats become truly useful when you combine them with: active requests, waiting tasks, and top queries. If you want a deeper “DBA thinking” approach, keep this bookmarked: Troubleshooting Common SQL Server Performance Issues (DBA Perspective) .

Printable Wait Stats Cheat Sheet (Top Waits → What to Check Next)

Use this table as a fast interpretation guide. Don’t treat it like a magic decoder ring—treat it like a “next best test” list that helps you confirm root cause without guessing.

If you want this as a PDF handout, add a “Download Cheat Sheet” button below (optional).

Read-only script pack (baseline + deltas)

These are safe “visibility scripts” you can run in production. The key is capturing deltas. Run baseline, wait 5–15 minutes during the symptom, then compare.

1) Create a temp table to store snapshots

IF OBJECT_ID('tempdb..#WaitSnapshot') IS NOT NULL DROP TABLE #WaitSnapshot;

CREATE TABLE #WaitSnapshot
(
    capture_time      datetime2(0) NOT NULL DEFAULT SYSDATETIME(),
    wait_type         nvarchar(120) NOT NULL,
    wait_time_ms      bigint NOT NULL,
    signal_wait_time_ms bigint NOT NULL,
    waiting_tasks_count bigint NOT NULL
);

2) Insert a baseline snapshot

INSERT INTO #WaitSnapshot (wait_type, wait_time_ms, signal_wait_time_ms, waiting_tasks_count)
SELECT
    wait_type,
    wait_time_ms,
    signal_wait_time_ms,
    waiting_tasks_count
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE 'SLEEP%';

3) After 5–15 minutes, run this again (second snapshot)

WAITFOR DELAY '00:10:00';  -- adjust as needed

INSERT INTO #WaitSnapshot (wait_type, wait_time_ms, signal_wait_time_ms, waiting_tasks_count)
SELECT
    wait_type,
    wait_time_ms,
    signal_wait_time_ms,
    waiting_tasks_count
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE 'SLEEP%';

4) Compare deltas (what increased the most)

;WITH ranked AS
(
    SELECT
        a.wait_type,
        a.capture_time AS t1,
        b.capture_time AS t2,
        b.wait_time_ms - a.wait_time_ms AS delta_wait_ms,
        b.signal_wait_time_ms - a.signal_wait_time_ms AS delta_signal_ms,
        b.waiting_tasks_count - a.waiting_tasks_count AS delta_tasks
    FROM #WaitSnapshot a
    JOIN #WaitSnapshot b
      ON a.wait_type = b.wait_type
     AND a.capture_time = (SELECT MIN(capture_time) FROM #WaitSnapshot)
     AND b.capture_time = (SELECT MAX(capture_time) FROM #WaitSnapshot)
)
SELECT TOP (20)
    wait_type,
    delta_wait_ms / 1000.0 AS delta_wait_seconds,
    delta_signal_ms / 1000.0 AS delta_signal_seconds,
    delta_tasks
FROM ranked
WHERE delta_wait_ms > 0
ORDER BY delta_wait_ms DESC;

5) Confirm with waiting tasks (the real-time queue)

SELECT TOP (100)
    wt.session_id,
    wt.wait_type,
    wt.wait_duration_ms,
    wt.blocking_session_id,
    wt.resource_description
FROM sys.dm_os_waiting_tasks wt
WHERE wt.session_id > 50
ORDER BY wt.wait_duration_ms DESC;

If you want a larger “production kit” (backups, jobs, blocking, I/O latency, top queries), use: SQL Server DBA Scripts (All-in-One) .

A simple triage workflow that doesn’t lie to you

1. Start with the symptom: timeouts, slow reports, blocked app threads, high CPU, disk alerts.
2. Capture wait delta: what wait types grew during the symptom window.
3. Confirm with “who is waiting”: waiting tasks + active requests.
4. Find the workload source: top CPU/read/write queries, or head blocker.
5. Apply the lowest-risk mitigation: stop the offender, reduce concurrency, or fix the top query.
6. Document and prevent: add alerting, schedule changes, indexing backlog, Query Store review.

If you’re currently in an outage situation, use the incident timeline runbook: Timeouts & Blocking Incident Runbook.

Fix playbooks: what to do after you identify the wait family

Playbook 1: I/O waits (PAGEIOLATCH_*)

• Confirm file-level latency (dm_io_virtual_file_stats) and identify the database/file under pressure.
• Identify top read-heavy queries (Query Store or dm_exec_query_stats) and look for large scans.
• Fix the workload first: indexing/query changes usually beat “hardware guessing.”

Playbook 2: Logging pressure (WRITELOG)

• Confirm log volume saturation and overlapping jobs (backups, ETL, index maintenance).
• Identify transaction-heavy operations (batch size, autocommit loops, bulk operations).
• Reduce commit frequency or batch intelligently; avoid stacking heavy maintenance at peak.

Playbook 3: Locking waits (LCK_M_*)

• Find the head blocker and confirm if it’s a long transaction or a batch stuck on I/O.
• Check if a missing index is turning a small update into a large locked scan.
• Mitigate with approvals: stop the offender or reduce the collision pattern in the application logic.

Playbook 4: CPU waits (SOS_SCHEDULER_YIELD)

• Find top CPU queries and compare “before vs after” if a regression is suspected.
• Look for one offender query shape that changed (plan regression, parameter sensitivity).
• Apply targeted fixes first; avoid blanket configuration changes during the incident.

Playbook 5: Parallelism waits (CXPACKET / CXCONSUMER)

• Don’t panic. Parallelism waits can be normal on busy systems.
• Confirm CPU pressure exists and identify the expensive parallel query.
• Tune the query/index first; only then evaluate instance-level parallelism settings with care.

For structured learning that turns these playbooks into job-ready skills: SQL Server DBA Training & Certification and your placement path: Careers at SQL DBA School .

Common mistakes that waste hours

• Chasing the top wait name without a delta. Fix: compare snapshots taken during the symptom window.
• Assuming “CXPACKET means fix MAXDOP.” Fix: identify the actual expensive query first.
• Changing configuration during an incident. Fix: stabilize workload sources first; tune later with evidence.
• Ignoring client-side behavior. Fix: ASYNC_NETWORK_IO often indicates slow result consumption, not SQL’s core speed.
• No documentation. Fix: save outputs + a 3-bullet incident summary (your future self will thank you).

FAQ