What is the issue?
Always On Availability Group replicas maintain a connection state that reflects whether each secondary is actively communicating with the primary. The state is recorded in sys.dm_hadr_availability_replica_states as either CONNECTED (the replica is in communication with the primary) or DISCONNECTED (the replica is not).
A replica in a DISCONNECTED state is running as a SQL Server instance but is not exchanging traffic with the primary through the AG endpoint. The instance may be entirely healthy from a local perspective, with the databases online and the service responsive, while contributing nothing to the availability of the AG.
This finding identifies AGs where one or more replicas are in a DISCONNECTED state.
Why is this a problem?
A disconnected replica is not receiving log records from the primary, so its copy of each database is frozen at whatever point it reached before the connection dropped. Every transaction that commits on the primary widens the gap, and the replica becomes progressively less useful as a recovery option the longer the disconnection persists.
The disconnected replica is also not a valid failover target. Automatic failover cannot occur to a disconnected replica, and a manual failover would either fail or require accepting the data loss represented by the accumulated gap. The AG has effectively lost that replica from its availability model until the connection is restored.
Disconnection also affects the primary. Log records that have not been delivered to all replicas cannot be truncated, so the primary’s transaction log can grow continuously while a replica remains disconnected. If the disconnection persists long enough, the primary’s log volume can fill and cause the AG to stop accepting writes, turning a secondary-side problem into a full outage.
The condition often goes unnoticed because the primary continues to function normally for client operations. Applications connect and work, the databases are accessible, and monitoring focused on the primary shows no issues. Only monitoring that specifically checks replica connection state will surface the problem before the log growth or a failed failover attempt makes it obvious.
What should you do about this?
Identify the affected replicas by querying sys.dm_hadr_availability_replica_states for rows where connected_state_desc is DISCONNECTED. Confirm the affected replica’s SQL Server service is running and that the instance is otherwise healthy before assuming the issue is network-related.
Check the AG endpoint on both the disconnected replica and the primary, confirming the endpoint is in the STARTED state and that the required CONNECT permissions are granted to each partner replica’s service account. Verify network connectivity between the replicas on the endpoint port (5022 by default), including any firewall rules on the hosts and any network-level access control between the subnets involved.
Review the SQL Server error log on both the primary and the disconnected replica, along with the AlwaysOn_health Extended Events session, to identify when the connection dropped and what error was recorded. The error text usually indicates whether the cause was a network failure, an authentication problem, an endpoint state change, or a timeout, which directs the remediation.
Once connectivity is restored, monitor the replica’s catch-up progress and confirm it returns to CONNECTED and to a healthy synchronization state. Monitor the primary’s transaction log size during catch-up, since the log will not begin truncating until the replica is current. Add connection state monitoring to your standard AG alerting so future disconnections are detected within minutes rather than discovered through log growth or a failed failover.