Fix ERROR_HOST_NODE_NOT_AVAILABLE 0X0000138D in Windows Failover Cluster
This error means a cluster node dropped out or isn't reachable. Start with a quick ping test, then check cluster service health, then rebuild quorum.
The 30-Second Fix: Quick Connectivity Check
Don't overthink this. The culprit here is almost always a network blip or a node that lost heartbeat. Open PowerShell as admin on any reachable cluster node and run:
Test-NetConnection -ComputerName <problem-node-name> -Port 3343If that fails, check if the node is even powered on. If the node's up but the port's blocked, you've got a firewall or VLAN issue. Also quickly check the cluster's view:
Get-ClusterNodeIf the node shows as 'Down', it's not just a communication glitch — the cluster service itself probably crashed.
The 5-Minute Fix: Restart Cluster Service and Check Logs
Still broken? Log into the problem node directly. Restart the Cluster service — yes, it's that simple sometimes:
Restart-Service -Name ClusSvc -ForceWait 30 seconds, then run Get-ClusterNode again from another node. If the node comes back as 'Up', you're done. If not, check the System Event Log for anything from source 'ClusSvc' or 'FailoverClustering'. Look for errors around the time of the failure — disk timeouts, DNS resolution failures, or storage path disconnects are common triggers.
Common real-world triggers
I've seen this error pop up after a Windows Update reboot where the node came back before the storage controller driver fully loaded. Also after a power outage where one node's UPS failed but the other's didn't. In those cases, a simple Restart-Service — or a full reboot — clears it.
The 15+ Minute Fix: Validate Cluster and Rebuild Quorum
If the node stays 'Down' after a restart, you've got a deeper issue. Don't bother with random regedits — go straight to cluster validation. On a healthy node, run:
Test-Cluster -Node <all-node-names>This checks network, storage, and configuration. Any failures mean you need to fix those before the cluster will work. Common fails: mismatched DNS records, duplicate IPs, or one node missing a CSV volume. Fix those, re-run validation until all pass.
If quorum is lost — meaning we have an even number of nodes or a witness failure — you might need to force quorum. Do this only if you're sure the other nodes are dead:
Stop-Service ClusSvc
Start-Service ClusSvc -ArgumentList '/ForceQuorum'Then add remaining nodes one by one. After the cluster is stable, run Set-ClusterQuorum -NoWitness or reconfigure your witness (file share or cloud witness). I prefer a cloud witness for modern setups — it's bulletproof.
When All Else Fails
If validation passes but the node still won't join, drain the node, remove it from the cluster:
Remove-ClusterNode -Name <problem-node>Reboot that node, re-add it:
Add-ClusterNode -Name <problem-node>This forces a fresh join and clears any stale state.
Pro tip: Always check DNS first. A missing or wrong A record for the node's cluster IP will cause this error every time. I've seen it more often than any actual hardware failure.
If you're still stuck, collect the cluster logs from all nodes:
Get-ClusterLog -Destination C:\ClusterLogsLook for lines containing '0x0000138d' or 'HOST_NODE_NOT_AVAILABLE' — the context around those will tell you exactly which resource or path failed.
Was this solution helpful?