Fix ERROR_CLUSTER_NODE_DOWN (0X000013BA) – Node Offline

Quick Answer

Advanced users: Run Get-ClusterNode | Format-Table -Property Name, State in PowerShell on a surviving node. If the failed node shows “Down,” check its network cables and DNS. Then restart the Cluster service on the down node: Restart-Service -Name ClusSvc. If that fails, force a quorum repair with Get-Cluster | Repair-ClusterQuorum.

Why This Error Appears

ERROR_CLUSTER_NODE_DOWN happens when a node in a Windows Failover Cluster stops talking to the other nodes. The cluster runs a heartbeat every few seconds over the network. If one node misses too many heartbeats (default is 5 seconds of silence), the cluster marks it as down. This can happen for many reasons: a bad network cable, a switch port that went dead, a Windows update that forced a reboot, or a hung Cluster service. I've seen this most often after someone accidentally unplugs a node during a server room cleanup. The error code 0X000013BA translates to “The cluster node is down.” Your cluster loses high availability until you bring that node back.

Step-by-Step Fix

Before you start, make sure you're logged into the affected node or can access it remotely. You'll need administrator rights on all cluster nodes.

Step 1: Check Physical and Network Connectivity

• Look at the node. Is the power light on? Are the network port LEDs blinking? If the node is a VM, check the hypervisor console.
• Ping the node from another cluster node. Open Command Prompt on a working node and type: ping . If it times out, the node is unreachable. Check the switch port and cable.
• Check DNS. Run nslookup to see if the IP resolves correctly. Cluster nodes talk to each other by hostname. If DNS is wrong, the heartbeat fails.

After you fix any network issue, the node should automatically rejoin the cluster within 30 seconds. If not, move to Step 2.

Step 2: Restart the Cluster Service

On the down node, open PowerShell as Administrator and run:

Restart-Service -Name ClusSvc -Force

Wait 20 seconds. Then check the cluster state from a different node:

Get-ClusterNode

You should see the node change from “Down” to “Up” after a minute. If it remains down, the service might not be starting. Check the Windows Event Log under “FailoverClustering” for errors.

Step 3: Validate and Repair Quorum

Sometimes the cluster itself has a quorum problem that keeps the node out. On a surviving node, run:

Test-Cluster

If the report shows warnings about quorum, fix it with:

Get-Cluster | Repair-ClusterQuorum

This will rebuild the quorum configuration. After that, restart the Cluster service on the down node again.

Step 4: Force Node Eviction (Last Resort)

If the node still won't come up, you might need to evict and re-add it. On a working node, run:

Remove-ClusterNode -Name  -Force

Then on the down node, after fixing whatever caused the issue (like a disk or network problem), run:

Add-ClusterNode -Name 

This is drastic. It clears the node's cluster database. The node will rejoin fresh, but you'll lose any role state from that node. Good for hardware replacements.

Alternative Fixes If the Main Steps Fail

• Check Windows Firewall. The cluster uses ports 3343 (TCP/UDP) and 445 (TCP). Make sure they aren't blocked. On the down node, temporarily disable the firewall: netsh advfirewall set allprofiles state off. If the node comes up, you found the problem. Re-enable the firewall and create proper rules.
• Review the Cluster Log. Each node stores a log at %SystemRoot%\Cluster\Cluster.log. Open it with Notepad. Search for “0x000013BA” or “down.” You'll see the exact time the node was marked down and why. Common reasons: “Node lost communication” or “Node failed to respond to join request.”
• Check Storage. If the cluster uses shared storage (like iSCSI or Fibre Channel), make sure the down node can see the disks. Run Get-ClusterAvailableDisk on the down node. If no disks show, the storage path is broken.

Prevention Tip

Set up your cluster network with redundancy. Use at least two separate network adapters for heartbeat traffic – one for internal cluster communication, one for client traffic. Use crossover cables or a dedicated VLAN for the heartbeat. In Windows Server 2019 and later, you can configure “cluster networks” in Failover Cluster Manager to separate heartbeat from client data. Also, monitor node health with a simple PowerShell script that emails you if a node drops. I've used this one-liner as a scheduled task:

$nodes = Get-ClusterNode | Where-Object {$_.State -eq 'Down'}; if ($nodes) { Send-MailMessage -To 'admin@domain.com' -From 'cluster@domain.com' -Subject 'Node Down Alert' -Body $nodes.Name }

That catches problems within minutes, not hours.