Azure SQL Database write log % alert


The Write Log % alert notifies you when its configured condition is met on Azure SQL Database instances so you can investigate and respond.

Screenshot pending: Mini DBA Azure SQL Database Write Log % alert screenshot placeholder

Alert summary

  • Platform: Azure SQL Database
  • Alert category: Disk
  • Default enabled: true
  • Default evaluation frequency: Minute
  • Threshold label: % Log IO
  • Unit: %

What Mini DBA checks

Mini DBA describes this alert as: % of Log Write used by this database Sustained high usage may indicate poor T-SQL or index design or a need to upgrade service tier Mini DBA evaluates this alert once a minute so changes are detected quickly. Because duration is used, Mini DBA can avoid treating a single short spike as a full incident when the condition clears quickly.

How this alert helps

This alert shows that Azure SQL log-write resource use is approaching the service-tier limit. Sustained high utilisation can throttle write-heavy transactions and increase commit latency.

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: % Log IO. Major threshold: 95 %. Minor threshold: 85 %. Comparison direction: over. Duration is used, so prefer requiring the condition to persist before paging people for transient spikes. 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

Review write-heavy statements, transaction batching, index maintenance, and recent workload growth alongside Azure SQL log-write utilisation. Reduce avoidable log generation or move the database to a service tier with enough write capacity when sustained demand is legitimate.

Investigation workflow

  1. Confirm the utilisation level, duration, database, and affected workload window.
  2. Compare log-write percentage with transaction rate, commit latency, waits, index maintenance, and recent deployments.
  3. Identify avoidable write amplification or batching patterns before changing the service tier.
  4. Validate that utilisation and user latency return to acceptable levels after remediation.

Avoiding alert noise

Require sustained utilisation before escalating and account for known load or maintenance windows. Keep thresholds below the point where Azure SQL throttling becomes user-visible.

Related pages