[Rudi Bruchez (rudi-bruchez)]

What's wrong

availability-modes-always-on-availability-groups.md says the primary waits for a synchronous secondary "unless the secondary replica fails to ping the primary replica within the primary's session-timeout period", and the note below repeats "the primary replica's session-timeout period". When the two replicas have different SESSION_TIMEOUT values, the commit waits for the longer of the two, not for the primary's value.

sys-availability-replicas-transact-sql.md says that on a failed connection the primary considers the secondary NOT_SYNCHRONIZED. NOT_SYNCHRONIZED isn't a state value; the synchronization state that sys.dm_hadr_database_replica_states.synchronization_state_desc shows for the secondary databases is NOT SYNCHRONIZING, as the availability modes page already says.

Evidence

SQL Server 2019 CU32-GDR (15.0.4480.2), 2022 CU26 (16.0.4265.3) and 2025 CU9-GDR (17.0.5015.4), Developer, Linux containers. Two-replica availability group, CLUSTER_TYPE = NONE, both replicas SYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, a fresh database with one table. A loop on the primary inserts one row every 200 ms and records each INSERT duration. The secondary is frozen with podman pause (processes stopped, TCP connections kept open). One run with podman kill instead (2025, 10 / 10) waited 9,838 ms.

-- on the primary, then freeze the secondary
ALTER AVAILABILITY GROUP [agSync] MODIFY REPLICA ON N'<primary>' WITH (SESSION_TIMEOUT = 5);
ALTER AVAILABILITY GROUP [agSync] MODIFY REPLICA ON N'<secondary>' WITH (SESSION_TIMEOUT = 20);

Longest INSERT wait after freezing the secondary:

Primary / secondary SESSION_TIMEOUT	2025	2022	2019
10 / 10	9,818 to 9,969 ms	9,851 to 9,903 ms	9,822 to 9,888 ms
5 / 20	19,822 and 19,883 ms	19,818 ms	19,825 ms
20 / 5	19,978 and 19,826 ms	19,843 ms	19,826 ms
10 / 30 and 30 / 10	29,832 and 29,809 ms	not measured	not measured

Same test on Windows: SQL Server 2025 CU9-GDR (17.0.5015.4), Enterprise Developer, Windows Server 2019, two-node WSFC, a dedicated availability group (CLUSTER_TYPE = WSFC, both replicas SYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL) with a fresh database. The secondary's sqlservr.exe is frozen with NtSuspendProcess (the node and its cluster service keep running), one run per setting:

Primary / secondary SESSION_TIMEOUT	Longest INSERT wait
10 / 10	9,797 ms
5 / 20	19,797 ms
20 / 5	19,797 ms
10 / 30	29,750 ms
30 / 10	29,813 ms

Not measured on Pacemaker.

After the timeout (2025, Linux and Windows), synchronization_state_desc for the secondary database is NOT SYNCHRONIZING and connected_state_desc is DISCONNECTED.

Observed: the wait matches the longer of the two values, on Linux without a cluster and on Windows with WSFC. Expected per the current text: the primary's value (5 s in the 5 / 20 case).

Change

Removes "primary's" from the two places that name the period, states once, in the paragraph, that the longer of the two values applies, points the note's default value to the session-timeout section of the overview, and describes the failed connection in sys.availability_replicas with the database synchronization state the DMV shows.

[learn-build-service-prod]

Learn Build status updates of commit 7733f71:

✅ Validation status: passed

File	Status	Preview URL	Details
docs/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups.md	✅Succeeded
docs/relational-databases/system-catalog-views/sys-availability-replicas-transact-sql.md	✅Succeeded

For more details, please refer to the build report.

[Courtney Wales (Court72)]

Rudi Bruchez (@rudi-bruchez),

Thank you for your contribution. Would you take a moment to sign the Contributor License Agreement (CLA)? After the CLA is signed, someone can review your pull request. Thanks!

[Courtney Wales (Court72)]

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

[Rudi Bruchez (rudi-bruchez)]

@microsoft-github-policy-service agree

[prmerger-automator]

Rudi Bruchez (@rudi-bruchez) : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. Randolph West MSFT (@rwestMSFT)

[Courtney Wales (Court72)]

Masha Thomas (MSFT) (@MashaMSFT)

Can you review the proposed changes?

Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.