SQL Server Always On transaction delay alert


The Always On Transaction Delay 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 Always On Transaction Delay alert screenshot placeholder

Alert summary

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

What Mini DBA checks

Mini DBA describes this alert as: The delay for a synchronous primary replica database which has to wait for secondary replicas to harden the sent log data before it can commit any more transactions. Mini DBA evaluates this alert once a minute so changes are detected quickly.

How this alert helps

This alert measures synchronous-commit delay while the primary waits for secondary replicas to harden log records. Sustained delay directly increases commit latency on the primary.

When to enable it

Enable it where replication, read replicas, failover, or reporting copies are part of the service design. Disable it on standalone systems that do not use replication so the alert list stays focused.

Threshold guidance

Threshold meaning: Milliseconds. Major threshold: 5000 Ms. Minor threshold: 2000 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

Compare primary log flush time with replica hardening, send and redo queues, network latency, secondary storage, and replica workload. Correct the constrained transport, log-write, or secondary resource before changing availability mode or application transactions.

Investigation workflow

  1. Record the affected availability group, database, replicas, delay, and first-seen time.
  2. Compare primary log flush, network latency, send and redo queues, and secondary log-write performance.
  3. Check replica health, recent failovers, maintenance, and workload changes on both sides.
  4. Confirm synchronous commit latency returns to baseline before changing alert thresholds.

Avoiding alert noise

Use duration to ignore isolated network or log-flush stalls, but keep a tight threshold where synchronous commit is required for the recovery objective and user transactions are latency-sensitive.

Related pages