Use the Wait Ms Per Sec alert in Mini DBA to monitor Azure SQL Database instances and make this condition visible before it becomes a wider database incident.
Mini DBA describes this alert as: Wait Milliseconds Per Sec (multiple cores will make it potentially greater than 1000 Ms) The MaxThreshold represents the number of Milliseconds requests wait per second that will trigger the alarm
This alert highlights concurrency pressure. Blocking, long sessions, and lock waits can turn a healthy server into a slow user experience, so the alert gives administrators an early route to the sessions, statements, and applications involved.
Enable it on any monitored Azure SQL Database instance where this condition would require an administrator to investigate or communicate with the application team. Tune noisy development systems after you have a short baseline.
Threshold meaning: Ms per second. Major threshold: 8000 milliseconds. Comparison direction: "over". Use higher thresholds on batch-heavy, development, or intentionally bursty systems where brief pressure is expected. Use lower thresholds on latency-sensitive production systems, small instances with little headroom, and services with strict recovery or availability commitments.
Open the related Mini DBA page for the instance, compare the current value with the recent baseline, identify whether the change is caused by workload, configuration, host capacity, or maintenance, then record the corrective action in the incident notes.
If this alert is noisy, check whether the workload naturally has short bursts. Raise the duration or threshold for expected batch windows, but keep a lower route for production systems where user-facing latency matters. Avoid simply disabling the alert until you know whether the noise is caused by threshold choice or by a real capacity trend.