Windows Server · critical · Directory & core infrastructure

Failover Cluster event 1135 — a node was removed from the active failover cluster membership

A node stopped answering cluster heartbeats for long enough that the rest of the cluster evicted it from membership, moving its workloads.

What you see

Event 1135 in the System log naming a node. Roles fail over unexpectedly, sometimes repeatedly. Often at the same time each day, which is a strong clue.

What is actually wrong

Almost never an actual node failure. Network loss, antivirus scanning cluster traffic, NIC power management, backups saturating the heartbeat network, or a VM host pausing the guest long enough to miss heartbeats.

Codes and articles

1135Event 1135Event 1146Event 1069

Fixes (2)

Rule out the network and the NIC settings

Elevated PowerShell on each node1 hourlow riskreversible

No obvious time pattern.

Collect the cluster log around the eviction — it records the heartbeat misses in detail.
PowerShell
```
Get-ClusterLog -TimeSpan 15 -Destination C:\temp
```
Turn off power management on every cluster NIC.
PowerShell
```
Get-NetAdapter | Get-NetAdapterPowerManagement | Where-Object AllowComputerToTurnOffDevice -eq 'Enabled'
```
A NIC allowed to sleep will drop heartbeats on an otherwise idle network, which produces exactly this event at unpredictable times.

Disable it where enabled.

PowerShell

Set-NetAdapterPowerManagement -Name 'Cluster' -AllowComputerToTurnOffDevice Disabled

Exclude cluster traffic and the cluster directories from antivirus on-access scanning.
Check the cluster network configuration is sane — at least one network dedicated to cluster communication.
PowerShell
```
Get-ClusterNetwork | Format-Table Name, Role, Address, State -AutoSize
```
Only if the physical network is known-good and cannot be improved, relax the heartbeat thresholds.
PowerShell
```
(Get-Cluster).SameSubnetDelay = 1000(Get-Cluster).SameSubnetThreshold = 10
```
This is a last resort. It makes the cluster slower to detect a genuine node failure — it hides the symptom rather than fixing the cause.

Confirm it workedNo further 1135 events over a full week.

PowerShell

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1135} -MaxEvents 20 | Format-Table TimeCreated, Message -AutoSize

If you need to undo itReturn SameSubnetDelay to 1000 and SameSubnetThreshold to 5 (the defaults for recent versions) if you changed them.

Find the scheduled load that is starving the heartbeat

Elevated PowerShell1 hourlow riskreversible

Evictions cluster around a particular time.

Note the exact times from the event log and look for what else runs then.

PowerShell

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1135} -MaxEvents 30 | Select-Object TimeCreated

Check backup schedules first — a backup reading a CSV at full speed is the classic cause.

Check for scheduled antivirus full scans.

PowerShell

Get-MpPreference | Select-Object ScanScheduleDay, ScanScheduleTime

Separate the heartbeat onto its own physical network if it currently shares with storage or backup traffic.
If the nodes are virtual, check the host for the same window — host-level backups that quiesce a guest will pause it past the heartbeat threshold.

Confirm it workedThe window passes without an eviction.

If you need to undo itNone — this is scheduling and topology, not configuration to undo.

Reference

Troubleshoot cluster event 1135 — Microsoft Learn ↗

Related faults

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.