What’s the issue?
Each replica in an Always On Availability Group is configured with a failover mode, set as either AUTOMATIC or MANUAL. Automatic failover allows SQL Server to fail the AG over to a secondary without administrator intervention when health conditions warrant, while manual failover requires a deliberate action by an administrator to initiate the role change.
Failover mode is closely tied to the availability mode of each replica. Automatic failover is only available between replicas configured with SYNCHRONOUS_COMMIT availability mode, since automatic failover requires that the secondary be guaranteed up to date. Asynchronous replicas always require manual failover.
This finding identifies AGs or instances where the failover modes are inconsistent, either with different replicas in the same AG using different failover modes, or with replicas hosted on the same instance configured differently across multiple AGs.
Why is this a problem?
Inconsistent failover modes within an AG can produce unexpected behavior during a failure event. If the primary fails and the only synchronous replica is configured for manual failover while another replica is configured for automatic, the actual failover behavior depends on which secondary the cluster considers eligible at the moment of failure, which can lead to longer outages than the team expects.
Inconsistent modes across multiple AGs on the same instance create operational complexity that is easy to misjudge during incidents. An administrator responding to a failure may correctly invoke automatic failover behavior for one AG while an adjacent AG on the same host requires manual intervention, extending the overall recovery time and increasing the chance of mistakes under pressure.
The configuration can also indicate that the AG topology has changed from its original design. AGs are typically designed with a deliberate failover model (high availability with automatic failover, disaster recovery with manual failover, or a mix), and inconsistent settings often reflect changes made over time without revisiting the overall design.
In some cases the inconsistency is intentional, such as a multi-region AG where the local replicas are configured for automatic failover within the primary site while the remote disaster recovery replica is manual. The condition is worth reviewing in either case to confirm the configuration is deliberate and matches the documented availability strategy.
What should you do about this?
Inventory the current failover and availability mode configuration for every replica in every AG by querying sys.availability_replicas and reviewing the failover_mode_desc and availability_mode_desc columns. Group the results by AG and by hosting instance to identify the inconsistencies.
For each AG, review the configuration with the team responsible for the availability design and confirm what the intended behavior is. Within a single AG, automatic failover should be configured consistently across all replicas that participate in the high availability tier (typically two or three synchronous replicas), with disaster recovery replicas explicitly designated as manual.
Adjust failover modes using ALTER AVAILABILITY GROUP [AGName] MODIFY REPLICA ON N’ReplicaName’ WITH (FAILOVER_MODE = AUTOMATIC); or the equivalent manual setting. Remember that automatic failover requires synchronous commit availability mode, so the two settings must be aligned.
Read more…
Failover modes for availability groups – SQL Server Always On | Microsoft Learn