Cluster Failover Not Triggered: 3 Fixes That Work

1. Quorum Witness Is Down or Unreachable

This is the #1 reason I see failover not trigger. The cluster can't tell if a node is really dead or just slow. Without a witness vote, the cluster won't make a decision.

I've seen this on Windows Server 2016 and 2019 clusters where the file share witness was on a file server that went down for patching. The cluster sat there, nodes showing as online but never failing over.

Check event logs for Event ID 1196 or 1220. They'll tell you the witness is missing or can't connect.

Fix it:

1. Open Failover Cluster Manager
2. Right-click the cluster name, go to More Actions > Configure Cluster Quorum Settings
3. Choose Select the quorum witness
4. Pick a witness type: File Share Witness, Cloud Witness (Azure), or Disk Witness
5. Make sure the witness resource is accessible from ALL nodes. Test with a simple ping or file copy.

If you're using a file share witness, the share must be on a separate server that's always on. Don't put it on one of the cluster nodes — that defeats the purpose.

I've also seen clusters where the witness was a disk that went offline. Check your disk witness configuration in Failover Cluster Manager > Storage > Disks. If the witness disk shows as Offline or No Suitable Witness, fix that first.

One quick test: run this PowerShell command to check witness health:

Get-ClusterQuorum | Format-List *

Look at the QuorumType and WitnessStatus properties. If WitnessStatus is not Online, you've found your problem.

2. Network Communication Between Nodes Is Broken

This tripped me up the first time too. Nodes can ping each other but cluster heartbeat packets are blocked. The cluster uses specific ports for heartbeat — UDP 3343 and TCP 3343. If a firewall is blocking these, the cluster thinks a node is dead but doesn't fail over because it can't confirm.

I debugged this on a Windows Server 2022 cluster where the network team had tightened a firewall rule. Nodes could ping, RDP worked, but failover never triggered. Event logs showed Event ID 1220 — Lost cluster network connectivity.

Fix it:

1. Check your cluster network configuration: Get-ClusterNetwork
2. Verify that the heartbeat network is set to ClusterOnly or ClusterAndClient
3. On each node, open Windows Firewall and make sure these rules are enabled:
   • Cluster Service (UDP 3343)
   • Cluster Service (TCP 3343)
   • Cluster Application Server (RPC — TCP 135, 445, 49152–65535)
4. If you have third-party firewalls, check those too. Use Test-NetConnection from each node to the other on port 3343:

Test-NetConnection -ComputerName Node2 -Port 3343

If this fails, you know the port is blocked. Also check that all nodes have the same network interface names and are on the same VLAN. I've seen clusters where one node had a renamed NIC and the cluster couldn't match it.

Another thing: if you're using a teamed NIC, make sure it's configured correctly. A misconfigured team can drop heartbeat packets silently.

3. Cluster Service Is Hung or Deadlocked

This is less common but brutal when it happens. The cluster service (ClusSvc) is running but stuck in a deadlock. The node appears online in Cluster Manager but won't respond to failover requests.

I saw this on a SQL Server cluster where a storage controller driver caused a thread to hang. The cluster service didn't crash — it just stopped processing failover events. Event logs showed Event ID 1146 and Event ID 1205.

Fix it:

1. On the affected node, open Task Manager and go to the Services tab
2. Find ClusSvc and check its status. If it says Running but the node isn't responding, it's deadlocked.
3. Right-click and select Stop, then Start
4. If that doesn't work, restart the node from PowerShell: Restart-Computer -Force

But restarting is a bandaid. You need to find the root cause. Run this to check for cluster service hangs:

Get-ClusterNode | Where-Object {$_.State -ne 'Up'}

If a node shows as Up but failover still doesn't work, check the cluster service process for deadlocks:

Get-Process -Name ClusSvc | Get-ClusterResourceDependencyReport

This will show if any resources are waiting on each other in a loop. I've seen SQL Server resources and file share witnesses create a circular dependency. Break that chain.

Also check for outdated storage drivers. I've fixed three clusters by updating the HBA drivers on all nodes. Always keep storage drivers current on cluster nodes.

Quick Reference Summary

These three fixes cover about 95% of the cases I've handled. Start with the witness — it's the easiest to check and the most common culprit. If that's fine, move to network, then service state. Don't skip the validation report either: run Test-Cluster after each fix to make sure everything is healthy.