SQL Server disk queue length alert


The Disk Queue Length alert notifies you when its configured condition is met on SQL Server instances so you can investigate and respond.

Screenshot pending: Mini DBA SQL Server Disk Queue Length alert screenshot placeholder

Alert summary

  • Platform: SQL Server
  • Alert category: Disk
  • Default enabled: true
  • Default evaluation frequency: Minute
  • Threshold label: Queued items
  • Unit: queued items

What Mini DBA checks

Mini DBA describes this alert as: IO items waiting to be serviced by the disk High disk queue length can signify poor IO configuration. Check if multiple databases sharing the same drive. The thresholds are device dependant so experiment with the settings Mini DBA evaluates this alert once a minute so changes are detected quickly.

How this alert helps

This alert highlights I/O requests waiting to be serviced by a disk or storage path. A sustained queue can indicate storage saturation, poor file placement, noisy neighbours, or an unsuitable device-specific threshold rather than low free space.

When to enable it

Enable it once the instance has a normal workload baseline. It is especially useful on busy OLTP, reporting, and integration systems where resource pressure can quickly become user-visible.

Threshold guidance

Threshold meaning: Queued items. Major threshold: 100 queued items. Minor threshold: 4 queued items. Comparison direction: over. For an over-threshold alert, decreasing a threshold makes that severity fire sooner; increasing it tolerates more load or pressure. Set the minor threshold as an early-warning level and the major threshold at the highest acceptable value for the service.

Remediation for an active alert

Identify the affected volume and files, then compare queue depth with latency, IOPS, throughput, database workload, maintenance, and other processes sharing the storage. Correct contention or layout problems and increase storage performance when sustained demand exceeds the device capability.

Investigation workflow

  1. Record the affected volume, queue length, latency, throughput, and first-seen time.
  2. Identify database files, workloads, maintenance jobs, and non-database processes using that storage path.
  3. Compare the queue with the device type and its normal baseline rather than applying one universal limit.
  4. Confirm that queue depth and user latency improve after remediation.

Avoiding alert noise

Storage alerts should usually stay enabled even on quiet systems because the impact of missing them is high. Tune warning thresholds to leave enough time for approval, provisioning, and validation, especially when storage changes are handled by another infrastructure team.

Related pages