SQL Server cluster node down: fix in 3 steps

Quick check (30 seconds): Is the node really down?

Before you dive into heavy troubleshooting, make sure you're not looking at a false alarm. Open Failover Cluster Manager on any cluster node. In the left pane, expand your cluster name, then click Nodes. Look at the Status column.

If the node shows Down, right-click it and select Move Core Cluster Resources — sometimes the cluster service just needs a kick. If the node comes back within 10 seconds, you're done. If it stays down, move on.

This happens most often after a Windows Update reboot or a network glitch. I've seen it on SQL Server 2019 Standard Edition clusters running on Windows Server 2019. The node is alive, but the cluster service lost its heartbeat connection temporarily.

Moderate fix (5 minutes): Restart the cluster service

The cluster service on the down node is probably stuck. You need to restart it from that node itself. But here's the catch — you can't RDP into it if it's fully offline. If you can RDP (the node is up, just cluster is down), skip to step 2.

Step 1: If you can't RDP, use a remote PowerShell session from another node. Open PowerShell as Administrator on any working cluster node. Run:

Enter-PSSession -ComputerName DownNodeName

Replace DownNodeName with the actual server name. If that fails, you'll need to hit the physical machine or use a management controller like iDRAC or iLO.

Step 2: Once you're on the down node, open PowerShell or CMD as Administrator. Run:

Stop-Service ClusSvc

Wait 10 seconds. Then:

Start-Service ClusSvc

After starting, open Failover Cluster Manager on your local machine. You should see the node status change from Down to Up within 30 seconds. If it stays down, the service might fail to start altogether. Check the System event log for Event ID 1135 — that's the classic "node removed from cluster" error.

If you see Event 1135, the problem is network-related. Skip the advanced fix — you'll need to check your NIC teaming settings and firewall rules for port 3343 (cluster UDP traffic).

Advanced fix (15+ minutes): Force a failover and rebuild the node

If the cluster service won't start or the node keeps dropping back down, you need to force the cluster to remove the bad node and then add it back. This is the nuclear option — take notes before you start.

Step 1: On any working cluster node, open Failover Cluster Manager. Right-click your cluster, go to More Actions → Force Quorum. This forces the cluster to form a quorum with the remaining nodes. Acknowledge the warning. The cluster might go into quarantine mode for up to 60 seconds.

Step 2: Now remove the broken node. Right-click the down node, select More Actions → Evict. Confirm. If the option is greyed out, you need to force it via PowerShell. Run:

Remove-ClusterNode -Name DownNodeName -Force

This removes it from the cluster configuration.

Step 3: On the broken node itself, open PowerShell as Administrator. Run:

Clear-ClusterNode

This wipes the local cluster database. Then reboot the server.

Step 4: After reboot, on the broken node, open Failover Cluster Manager. Right-click the cluster name in the left pane, select Add Node. Follow the wizard. You'll be asked for credentials — use a domain admin account with cluster permissions. The validation wizard might warn about storage or network settings — this is normal for a re-add. Click past the warnings (unless it's a critical storage mismatch).

Step 5: Once the node joins, move all cluster roles (SQL Server, MSDTC, file shares) back to it. Right-click each role in Failover Cluster Manager, select Move → Select Node, pick the rebuilt node. This shifts the workload back.

If the node drops again within a day, you've got a deeper hardware or driver issue. Check the network adapter drivers — I've seen Broadcom NetXtreme II adapters drop packets that look like cluster failures. Update to the latest driver from the OEM (not Microsoft Update). Also check for duplicate IP addresses in the cluster network — run

Get-ClusterNetwork -Cluster YourClusterName | fl *

in PowerShell to see if any subnets are showing Role 0 (that means disconnected).

One more thing: if your cluster uses storage spaces direct (S2D) on Windows Server 2016 or 2019, a node drop can corrupt the storage cache. After the node comes back, run

Get-StorageSubSystem -FriendlyName *Cluster* | Debug-StorageSubSystem

to check for health issues. I've lost a Saturday to this exact scenario.