What’s the issue?
Always On Availability Group replicas configured for synchronous-commit availability mode are expected to reach and maintain the SYNCHRONIZED state. In this state, SQL Server guarantees that every transaction committed on the primary has also been hardened to the log on the secondary before the commit is acknowledged to the client.
A synchronous-commit replica that is not synchronized is typically in SYNCHRONIZING, NOT SYNCHRONIZING, or a transient state such as REVERTING or INITIALIZING. In any of these states, the guarantee that synchronous mode provides does not currently apply.
This finding identifies AGs where one or more synchronous-commit replicas are not in the SYNCHRONIZED state, detected through sys.dm_hadr_database_replica_states and sys.availability_replicas.
Why is this a problem?
While a synchronous replica is not synchronized, there is no guarantee of zero data loss. Transactions committed on the primary during this window may not have been hardened on the secondary, so a failover would either fail or proceed only with data loss.
The database on the affected replica is also not a valid target for automatic failover, since the cluster only fails over automatically to replicas in the SYNCHRONIZED state. If the primary fails during this window, the AG becomes dependent on other replicas or on manual intervention, extending the outage beyond what the design intended.
The condition often persists because it does not disrupt normal client operations. The primary continues serving traffic and the AG may appear functional overall, so the availability gap can go unnoticed without monitoring that specifically checks replica synchronization state.
What should you do about this?
Identify the affected replicas and databases by querying sys.dm_hadr_database_replica_states joined to sys.availability_replicas, focusing on synchronous-commit replicas whose synchronization state is not SYNCHRONIZED. Capture the current state, synchronization health, and any suspend reason available.
Investigate the specific cause, since the common ones require different remediation. Suspended data movement is resolved with ALTER DATABASE [DatabaseName] SET HADR RESUME;, a redo backlog on the secondary points to storage or resource pressure that needs to be addressed there, and connectivity problems point to the endpoint state, firewall rules, or the network between replicas.
Monitor the catch-up process through the log send queue and redo queue sizes, and confirm the replica returns to SYNCHRONIZED before considering the issue resolved. Add synchronous replica state monitoring to your standard alerting so this condition is detected promptly rather than discovered when a failover is needed.