SQL Server average log write time alert


The Average Log Write Time 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 Average Log Write Time alert screenshot placeholder

Alert summary

  • Platform: SQL Server
  • Alert category: Disk
  • Default enabled: true
  • Default evaluation frequency: Minute
  • Threshold label: Milliseconds
  • Unit: Ms

What Mini DBA checks

Mini DBA describes this alert as: Average time in ms, the system has to wait for the IO subsystem to perform log writes This is an average number so will avoid sporadic peaks of the point in time version of this alert The figure is file specific and indicates a performance bottleneck around whichever drive the offending log file(s) are on Mini DBA evaluates this alert once a minute so changes are detected quickly.

How this alert helps

This alert identifies slow transaction-log writes. Log-write latency delays commit confirmation and can increase transaction response time even when the log has free capacity.

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: Milliseconds. Major threshold: 10000 Ms. Minor threshold: 500 Ms. 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 log file or Azure SQL time window, then compare write latency with commit waits, transaction rate, storage or service-tier limits, maintenance, and recent changes. Reduce avoidable log generation, correct storage contention, or increase storage and service capacity when the workload has outgrown it.

Investigation workflow

  1. Record the affected database or log file, latency, first-seen time, and whether the point-in-time or average alert fired.
  2. Compare log latency with commit waits, transaction rate, write throughput, service-tier utilisation, and maintenance activity.
  3. Check the underlying storage or Azure SQL resource evidence for saturation or transient faults.
  4. Confirm that commit and log-write latency return to baseline before changing thresholds.

Avoiding alert noise

Use duration and a normal log-latency baseline to separate isolated stalls from sustained commit pressure. Do not treat free disk space as proof that the log-write path is healthy.

Related pages