SQL Server Error 41131

Error number

41131

Severity

16 (user-correctable error)

State

0

Product

Microsoft SQL Server Database Engine

Versions

SQL Server 2016 to 2025 with Always On availability groups on a Windows Server Failover Cluster

Category

High Availability

Last reviewed

24 October 2026

What it means

Error 41131 means SQL Server created the availability group but the cluster could not bring its role online in time, most often because the NT AUTHORITY\SYSTEM login that Always On health detection uses is missing or lacks permissions.

When you create an availability group (or the cluster brings its role online on a new primary), the Windows Server Failover Cluster starts the availability group resource. The SQL Server resource DLL runs inside the cluster Resource Host Monitor (RHS.exe) as Local System and connects back to the instance as NT AUTHORITY\SYSTEM to start health detection. If that connection cannot log in or lacks permissions, the resource never reports online, SQL Server waits and gives up with 41131. The quoted name is the availability group.

Microsoft documents the missing NT AUTHORITY\SYSTEM login or permissions as the cause when 41131 appears during CREATE AVAILABILITY GROUP. The text itself also points to the cluster side: check that the local cluster node is online and that the availability group resource exists in the cluster. The sys.messages catalogue stores 41131 at severity 10, while the documented query window output shows it at level 16.

Common causes

• There is no SQL Server login for NT AUTHORITY\SYSTEM on the instance, for example because it was removed during security hardening.
• The login exists but lacks ALTER ANY AVAILABILITY GROUP, CONNECT SQL or VIEW SERVER STATE, or it is disabled or denied CONNECT SQL.
• The same gap on another replica: the group fails to come online when that replica must become primary.
• The local cluster node or the cluster service is not online, or the availability group resource is missing from the cluster.

Diagnose it

Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.

SELECT p.name, p.type_desc, p.is_disabled, sp.permission_name, sp.state_desc
FROM sys.server_principals AS p
LEFT JOIN sys.server_permissions AS sp ON sp.grantee_principal_id = p.principal_id
WHERE p.name = N'NT AUTHORITY\SYSTEM'
ORDER BY sp.permission_name;

SELECT c.cluster_name, c.quorum_state_desc, m.member_name, m.member_type_desc, m.member_state_desc
FROM sys.dm_hadr_cluster AS c
CROSS JOIN sys.dm_hadr_cluster_members AS m;

SELECT ag.name, ag.resource_id, ag.resource_group_id, ag.failure_condition_level,
       ag.health_check_timeout, ags.primary_replica, ags.synchronization_health_desc
FROM sys.availability_groups AS ag
LEFT JOIN sys.dm_hadr_availability_group_states AS ags ON ags.group_id = ag.group_id;

SELECT servicename, status_desc, service_account, is_clustered, cluster_nodename
FROM sys.dm_server_services;

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

# PowerShell on the cluster node: last 15 minutes, written to C:\Temp
Get-ClusterLog -Node $env:COMPUTERNAME -Destination C:\Temp -TimeSpan 15

USE master;
CREATE LOGIN [NT AUTHORITY\SYSTEM] FROM WINDOWS WITH DEFAULT_DATABASE = master;
GRANT ALTER ANY AVAILABILITY GROUP TO [NT AUTHORITY\SYSTEM];
GRANT CONNECT SQL TO [NT AUTHORITY\SYSTEM];
GRANT VIEW SERVER STATE TO [NT AUTHORITY\SYSTEM];

Examples

Creating an availability group when NT AUTHORITY\SYSTEM has no login

Shown as documented by Microsoft (KB 2847723), which gives the output as Msg 41131, Level 16, State 0 with the older wording (the line number here matches the one-statement script); not reproduced here because it needs a failover cluster. The newest engine wording adds "If this is a Windows Server Failover Clustering (WSFC) availability group". Server and database names are examples.

CREATE AVAILABILITY GROUP SalesAg
FOR DATABASE SalesDb
REPLICA ON N'SQL01' WITH (ENDPOINT_URL = N'TCP://SQL01.contoso.com:5022',
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC);

Msg 41131, Level 16, State 0, Line 1
Failed to bring availability group 'SalesAg' online. The operation timed out. Verify that the local Windows Server Failover Clustering (WSFC) node is online. Then verify that the availability group resource exists in the WSFC cluster. If the problem persists, you might need to drop the availability group and create it again.

How to prevent it

Include the NT AUTHORITY\SYSTEM login with its three permissions in the build checklist of every instance that will host an availability replica, and make sure security hardening scripts do not remove it. Microsoft notes the permissions must exist on every server that could host the primary replica, not only where the group was created.

Before creating a group, check cluster health and quorum, and keep a record of the cluster log after any failed attempt so the next try starts from the real cause.

Common questions

Learn more on CodeWithSQL

• SQL Server security: logins, users and permissions
• RDS Multi-AZ and read replicas

Official documentation

• Error 41131 when creating availability group
• Troubleshooting automatic failover problems in Always On environments
• sys.dm_hadr_cluster_members (Transact-SQL)
• Database engine events and errors (31000 to 41399)

Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.