Fix 0x80130002 cluster node already down error

What actually triggers 0x80130002

This error pops up when you try to bring a cluster node online, but the Failover Cluster service thinks it's already in a down state. I've seen this most often after a node lost quorum during a network blip — say, a switch rebooted and the heartbeat between nodes dropped for 10 seconds. The node went offline, but the cluster database didn't fully update. So when you click "Bring Online" in Failover Cluster Manager, it throws 0x80130002.

The good news: you don't need to rebuild or reinstall anything. The fix is usually a state reset. Let's work through it from quickest to most thorough.

Check if the node is really down (30 seconds)

First, confirm the cluster service isn't just hung. Open PowerShell as Administrator on the affected node and run:

Get-ClusterNode

Look at the State column. If it shows Down or Paused, that's expected. But sometimes it'll show Up — in which case the error is a red herring. Close Cluster Manager, reopen it, try again. I've seen stale UI cache cause this. Refresh it and retry.

If the node is truly down, move on.

Force the node online from PowerShell (5 minutes)

The UI won't always help here. Use the raw cluster command. Still in PowerShell, run:

Start-ClusterNode -Name "YourNodeName" -ForceQuorum

Replace YourNodeName with the actual node name. The -ForceQuorum flag tells the cluster to override the current state. This works maybe 70% of the time. Had a client last month whose entire SQL cluster went sideways because of a misconfigured VLAN — this got the secondary node back online in under a minute.

If that fails, try a softer approach — clear the node state:

Stop-ClusterNode -Name "YourNodeName"
Start-ClusterNode -Name "YourNodeName"

Sometimes the node just needs a full state reset. Stopping and starting the cluster service does that without a full reboot.

Check quorum configuration (10 minutes)

If the node still won't come online, the cluster likely lost quorum. Run:

Get-ClusterQuorum

Look at QuorumType. If it's NodeMajority and you only have two nodes, you're in trouble. A single node can't form a majority. You need a witness. Either enable a file share witness or disk witness.

To set a file share witness quickly:

Set-ClusterQuorum -FileShareWitness \\yourserver\sharename

Then retry Start-ClusterNode -ForceQuorum. This fixes the issue in most environments with two-node clusters.

Dive into the cluster log (advanced, 15+ minutes)

Still stuck? The cluster log tells the real story. Generate it on the problem node:

Get-ClusterLog -Destination C:\ClusterLogs -TimeSpan 5

Open the generated cluster.log file. Look for lines containing 0x80130002 or ALREADY_DOWN. You'll often see something like:

WARN: Node 'NodeA' is already in state down. Ignoring online request.

That means the cluster database has a stale entry. The fix is to clear the database cache. On the node still running (if any), run:

Stop-Service ClusSvc
Start-Service ClusSvc

This resets the cluster state for all nodes. On the problem node, then try Start-ClusterNode again. I've seen this resolve cases where nothing else worked — including one where a node had been down for 3 days after a power failure.

Last resort: Remove and re-add the node

If you're still stuck, evict the node from the cluster and rejoin it. On a working node (or the cluster owner), run:

Remove-ClusterNode -Name "YourNodeName"
Add-ClusterNode -Name "YourNodeName"

This forces a clean state. The node will need to re-sync, but it'll come online fresh. I've done this on a 2012 R2 cluster that had corrupt state after a failed backup — took about 10 minutes total.

Prevent it from happening again

This error usually traces back to network instability or quorum misconfiguration. If you're on a two-node cluster, always use a witness. Check your heartbeat network — dedicated VLAN, no teaming unless it's SET, and make sure jumbo frames match. I also recommend setting CrossSubnetDelay and SameSubnetDelay properly in cluster networks if you're stretched across sites.

One last thing: if you see this error repeatedly, check the cluster event log for past network disconnects. That's almost always the root cause — not the error itself.