Does SQL Server SESSION_TIMEOUT Cause an Availability Group Failover?

SESSION_TIMEOUT controls the connection between availability replicas. When a replica receives no ping within the limit, it closes that connection and marks the partner DISCONNECTED. That state alone is not the complete automatic-failover decision.

Last updated: October 7, 2026.

SELECT ar.replica_server_name,
       ars.role_desc,
       ars.connected_state_desc,
       ars.last_connect_error_number,
       ars.last_connect_error_description,
       ar.session_timeout
FROM sys.availability_replicas AS ar
JOIN sys.dm_hadr_availability_replica_states AS ars
  ON ars.replica_id = ar.replica_id;

-- Change only after measuring normal latency and diagnosing timeouts.
ALTER AVAILABILITY GROUP SalesAG
MODIFY REPLICA ON N'SQL02'
WITH (SESSION_TIMEOUT = 15);

The setting is per replica; Microsoft recommends keeping it at 10 seconds or greater. Raising it can reduce false disconnects on a slow link, but it also delays recognition of a genuinely broken replica connection. It does not repair CPU starvation, dropped packets, endpoint problems, or an unhealthy cluster. Capture a baseline of normal ping latency and disconnect frequency before changing the value, then confirm that every synchronous partner remains failover-ready after the change.

Automatic failover has additional requirements

Automatic failover requires a synchronous-commit failover partner configured for automatic failover, synchronized databases, WSFC quorum, and a failure condition recognized by the availability group’s flexible failover policy. A session timeout describes replica-to-replica communication; WSFC resource health and the SQL Server lease participate in the failover decision.

Microsoft’s availability group overview says a timed-out connection enters the disconnected state. Its failover-mode guide lists the separate prerequisites for automatic failover.

Diagnose the timeout before changing it

Correlate errors 35201, 35206, and 35267 with the AlwaysOn_health Extended Events session, SQL Server error logs, CPU pressure, non-yielding schedulers, worker exhaustion, and network traces. A brief disconnect can leave a synchronous secondary not synchronized and unable to take over safely. Monitor the send queue, redo queue, synchronization health, and is_failover_ready together; connection state alone does not describe recovery readiness.

Microsoft’s connection-timeout troubleshooting guide provides the relevant DMV and diagnostic sequence. Continue with encrypted SQL Server connections, certificate-chain troubleshooting, and restoring a backup to another server.

Related Web Cheat Sheet guides

Sergey Kornilov

Sergey Kornilov