STATUS_CLUSTER_NODE_UP (0XC0130012) – Cluster Node Is Up, But Not Joining

Cause 1: Stale Cluster State in the Node's Local Database

What's actually happening here is the node has a local copy of the cluster database (the CLUSDB) that's out of sync with the active cluster. The node boots, the Cluster Service starts, and it reports STATUS_CLUSTER_NODE_UP to indicate the service is running. But the node never successfully joins because its database fragment has a different version than what the quorum holds.

I've seen this after a forced failover where a node was offline during a quorum change, or after restoring a node from a snapshot without first pausing the cluster service. The node thinks it's part of a different configuration epoch.

Fix: Force a clean join by resetting the local cluster database

1. On the affected node, open an elevated PowerShell session.
2. Stop the Cluster service: Stop-Service ClusSvc
3. Clear the local cluster database—this is safe because the node has no quorum vote yet: Remove-Item -Path "HKLM:\Cluster\CLUSDB" -Recurse -Force
4. Delete the cluster hive file: Remove-Item -Path "$env:SystemRoot\Cluster\cluster.db" -Force
5. Start the Cluster service: Start-Service ClusSvc
6. The node now performs a full join, pulling the current cluster database from another node.

Why this works: The Remove-Item on the registry key and the cluster.db file wipes the local copy entirely. The cluster service then broadcasts a join request, and the node that holds the current epoch responds with the authoritative database. Without this, the service sees version conflicts and stays in a hung "up but not joined" state.

Cause 2: Network Connectivity or Misconfigured Cluster Network

The second most common cause is a network mismatch. The node's network adapter is up, but the cluster heartbeat or private network communication is actually failing. You get STATUS_CLUSTER_NODE_UP because the service started, but no other node can reach it for quorum or health checks.

This happens after adding a new NIC, changing VLANs, or when someone accidentally disables the cluster's dedicated heartbeat network (the one with "Cluster Only" or "Internal" role). I've also seen it when Windows Firewall blocks port 3343 (the cluster UDP port) or the nodes are on different subnets without proper routing.

Fix: Validate and repair cluster network configuration

1. Run the cluster validation wizard from Failover Cluster Manager: right-click your cluster, choose Validate Cluster, run all tests. Focus on Network and Heartbeat tests.
2. If the network test says "Network interface not reachable," check the adapter's configuration. In PowerShell: Get-ClusterNetwork -Cluster YOURCLUSTERNAME | Select Name, Status, Role, SubnetMask
3. Make sure each cluster node has at least two networks: one for public/client traffic, one for private heartbeat. The private network should have the role set to Internal or Cluster Only with unicast heartbeat enabled.
4. If you find a misconfiguration, use Set-ClusterNetwork -Name "Heartbeat" -Role ClusterOnly after correcting the NIC settings.
5. Restart the Cluster service on the affected node.

Why this works: The cluster uses a separate network for heartbeat to avoid latency from public traffic. If that network isn't functional, the node can't prove it's alive. Fixing the role and ensuring reachability lets the node participate in the cluster's health-check loop.

Cause 3: Node Quarantined or Blocked by Failover Cluster Manager

Sometimes the error isn't a database or network problem—it's that the cluster manager explicitly quarantined the node. This happens when a node failed repeatedly (e.g., from memory pressure or disk latency) and the cluster's anti-flapping logic kicked in. The node stays up, but is marked as quarantined, meaning it won't host any roles or join the quorum.

You'll see this after several quick crashes on the same node. The cluster raises STATUS_CLUSTER_NODE_UP because the service runs, but the node's State in PowerShell shows Quarantined or Unknown.

Fix: Clear the quarantine and restart the service

1. Open a Command Prompt as Administrator on a different node (one that's already active in the cluster).
2. Run: cluster node NODENAME /clearquarantine
3. Alternatively, use PowerShell: Clear-ClusterNodeQuarantine -Node NODENAME
4. Now restart the Cluster service on the quarantined node: Restart-Service ClusSvc -Force
5. Wait for the node to come back and check its state: Get-ClusterNode -Name NODENAME | fl State

Why this works: Quarantine is a protective mechanism—the cluster sets a timeout before allowing a flapping node to rejoin. Clearing it manually resets the timer. The node then goes through a normal join cycle and, if its underlying health is stable, will become a full member again.

Quick-Reference Summary Table

Try cause 1 first—it's the most frequent in real-world production clusters after maintenance windows or snapshots. Causes 2 and 3 are more common after hardware changes or repeated failures. If none of these work, run a full cluster validation and check the System event log for errors under FailoverClustering source.