Fix STATUS_CLUSTER_NODE_PAUSED Error 0XC0130013

This Error Means Your Node is Stuck in a Half-State

I know the feeling—you're staring at Failover Cluster Manager, the node shows Paused, and clicking Resume does nothing. The event log just gives you 0XC0130013. You've tried restarting the Cluster service, rebooting the node, even dancing on one foot. None of it worked. Here's what actually fixes it.

The Real Fix: Force Resume via PowerShell

The GUI Resume button is useless here. It tries a graceful rejoin, but the node's stuck waiting for something that won't happen—usually a DNS registration or a quorum response. You have to force it.

Run this on the node that's paused. Open PowerShell as Administrator.

Get-ClusterNode | Where-Object {$_.State -eq 'Paused'} | Resume-ClusterNode -Failback Immediate

If that errors out—and it will sometimes—add the -Force flag:

Get-ClusterNode | Where-Object {$_.State -eq 'Paused'} | Resume-ClusterNode -Failback Immediate -Force

Wait 30 seconds. Run Get-ClusterNode. If it shows Up, you're done. If it's still Paused, move on to the quorum fix below.

I've seen this work on Windows Server 2012 R2 through 2022. The Force flag skips the service-level handshake and tells the node to rejoin the cluster directly. It's the equivalent of pushing a stalled car—grab the bumper and shove.

Why Your Node Got Stuck in the First Place

The culprit here is almost always one of three things:

DNS registration failed. The cluster node couldn't register its network name. If the DNS client on the node has stale records or the reverse lookup zone is missing, the cluster service pauses the node instead of letting it join with a broken name. Check your DNS server—run ipconfig /registerdns on the node, then nslookup <nodename>. No response? Fix DNS first.
Quorum was lost temporarily. If the node lost contact with the quorum witness (file share witness or cloud witness), it paused itself. The cluster might have quorum again, but that node needs a kick. The PowerShell resume above handles this. If it doesn't, check the witness path is accessible. For a file share witness, make sure the share on the file server isn't offline.
Storage path timed out. The node couldn't reach its cluster disk within the timeout window (usually 20 seconds). This happens on iSCSI setups where the target goes unresponsive briefly. The node pauses to protect data. After the storage comes back, the node doesn't automatically rejoin—you need to force it.

Less Common Variations of This Issue

Node resumes manually but pauses again after 5–10 minutes

This means the root cause is recurring. DNS is failing to register the cluster's Client Access Point (CAP). Check the cluster's network name resource. Right-click it in Failover Cluster Manager, go to Properties, and look at the DNS registration tab. Uncheck "Register this connection's addresses in DNS" and recheck it. Then restart the Cluster service on the node. I've seen this pattern on domain controllers that have multiple NICs with different DNS servers.

Resume-ClusterNode returns "The cluster resource cannot be found"

This happens when the cluster's core resources (cluster name and IP) are offline on the node you're trying to resume. The resume command expects those to be online. You'll need to bring them online manually from another node. From a healthy node, run:

Get-ClusterResource -Name "Cluster Name" | Start-ClusterResource

Then try the resume again. If the cluster name resource won't start, you've got a network issue—duplicate IP or a dead NIC. Check the event log for event ID 1207 (IP address conflict).

Node is paused after a graceful shutdown or patching

Standard Windows Updates with a reboot shouldn't pause a node—they use the Cluster service's built-in drain mechanism. But if you manually ran Suspend-ClusterNode -Drain and the node never resumed, it's because the drain didn't complete. The cluster is waiting for all roles to move back. Check if any role is stuck in Failed state. Fix that role first (remove and add the disk or resource), then resume the node.

Prevention Steps So You Don't See This Again

This error is a symptom of weak cluster configuration. Here's what I tell every team after fixing it:

Set a static IP for the cluster node's NIC. Don't rely on DHCP for cluster nodes. DHCP renewals can cause brief DNS hiccups that trigger the pause. Use a reserved IP with zero lease time.
Configure the cluster to use a specific DNS server. In the cluster's network settings, set the DNS server to a known, stable DNS server—not the ISP's or a flaky DC. Use Get-ClusterNetwork -Name "Cluster Network 1" | Set-ClusterNetwork -DNSAddress "192.168.1.10".
Test your quorum witness path monthly. A simple script can verify the file share witness is accessible: Test-Path \\fileserver\clusterwitness. If it fails, fix the file share before it causes a node pause during a failover.
Enable cluster-aware updates. Let Windows Update handle draining and resuming nodes automatically. It handles the timing better than manual draining. Configure CAU in the cluster properties.

One last thing—if you're running a two-node cluster with a file share witness, make sure the witness is on a separate server. I've seen people put the witness on a node itself. That's a split-brain disaster waiting to happen. The witness must be on a third machine, ideally a low-end VM or a NAS.