Azure SQL Waits shows wait statistics for an Azure SQL database. Use it to identify the bottleneck category behind performance symptoms.
What Waits Help Explain
- CPU pressure.
- I/O pressure.
- Locking and blocking.
- Memory grant pressure.
- Service tier limitations.
- Application wait behavior.
Workflow
- Open Waits for the Azure SQL database.
- Review current interval deltas and accumulated wait data.
- Compare with Activity and Queries.
- Check Locks and Deadlocks if concurrency waits dominate.
How To Use Azure SQL Waits
Waits help explain the shape of Azure SQL performance problems. Lock waits point toward concurrency. I/O waits can point toward storage or service-tier pressure. CPU-related waits may mean query tuning, plan review, or service tier adjustment. Memory-related waits may point to grants, large sorts, hash joins, or workload concurrency.
Use waits as a map. After identifying the dominant wait, open the page that provides evidence for that category: Activity for live sessions, Queries and Query Store for statements, Locks and Deadlocks for concurrency, and Elastic Pools for shared pool pressure.
Azure SQL Waits FAQ
Are Azure SQL waits the same as SQL Server waits?
Many concepts overlap, but Azure SQL runs inside a managed platform with resource governance and service-tier limits. Always consider database and elastic pool capacity.
Should I tune waits directly?
No. Tune the cause. Waits tell you where time is spent; query, lock, pool, and service-tier pages help identify why.
Why do waits change by time window?
Workload mix changes. Review waits during the period users experienced the problem.
Next Steps From Wait Evidence
Wait evidence should guide the next page you open. Lock waits point to Locks, Deadlocks, and Activity. I/O or storage waits point to Files, Database Summary, and Elastic Pools. Query execution waits should be compared with Query Store and Queries. Capture the time window so the wait pattern can be matched to releases, jobs, or user reports.