What’s the issue?
HADR_SYNC_COMMIT is a SQL Server wait type that occurs on the primary replica of an Always On Availability Group when committing transactions on databases configured for synchronous-commit availability mode. The primary waits on this type while it sends the transaction’s log records to each synchronous secondary and waits for confirmation that the log has been hardened to disk on those secondaries.The wait time directly reflects the round-trip cost of synchronous replication, including network latency between replicas, log write performance on the secondaries, and any time spent in queues at either end. The wait is a normal and expected part of synchronous-commit operation, but the average duration is a useful indicator of how much synchronous replication is costing the workload.
This finding flags primaries where the average HADR_SYNC_COMMIT wait time has exceeded 5 milliseconds, which is a commonly accepted threshold for investigation.
Why is this a problem?
Every committed transaction on a synchronous-commit database pays the HADR_SYNC_COMMIT cost. When the average wait climbs above a few milliseconds, every commit takes longer, which translates directly into increased response time for write-heavy workloads and reduced throughput for transactional operations. Applications that perform many small commits feel this most acutely.Sustained high waits can indicate problems with the replication path or with the secondaries themselves. Network latency between replicas (often introduced when replicas live in different datacenters or cloud regions), slow storage on the secondaries causing delayed log hardening, or resource pressure on the secondary instances are all common causes. Each requires a different remediation, and the wait time alone does not identify which is at fault.
The condition can also indicate a topology mismatch. Synchronous-commit replicas should generally be physically and logically close to the primary so the round-trip is fast. Replicas located far away or on slower infrastructure are typically better configured for asynchronous-commit, accepting some recovery point objective tradeoff in exchange for not paying the latency cost on every commit.
Persistent elevated HADR_SYNC_COMMIT waits can also affect other parts of the system. Long commit waits hold transactional resources longer, which can cascade into blocking, increased lock contention, and elevated waits on other types. A small synchronization problem can produce broad performance symptoms that are hard to trace without specifically looking at AG-related waits.
What should you do about this?
Investigate the network path between the primary and the synchronous secondaries. Measure round-trip latency with simple ping and TCP-level tests, and compare against expected latency for the topology. High network latency is a common cause of elevated HADR_SYNC_COMMIT, particularly when synchronous secondaries are in remote datacenters or when network infrastructure has changed without a corresponding review of replica topology.Review log write performance on each synchronous secondary. Slow storage, contention from other workloads, or insufficient I/O capacity on the secondary can extend log hardening time and inflate the wait. Use the standard log write performance counters and dynamic management views (sys.dm_io_virtual_file_stats for log files) to compare write latency on each replica, and address any storage issues at the appropriate replica.
Evaluate whether each synchronous secondary genuinely needs to be in synchronous-commit mode. The synchronous setting is appropriate for replicas intended for automatic failover within a high-availability tier, typically located close to the primary. Replicas located far away or used primarily for disaster recovery or reporting are better suited to asynchronous-commit, which removes them from the HADR_SYNC_COMMIT path entirely. Adjust the availability mode on individual replicas using ALTER AVAILABILITY GROUP MODIFY REPLICA.