Cluster heartbeat timeout configuration

Quinn 20 Reputation points
2026-09-04T09:17:54.4166667+00:00

Hi guys

We’re seeing high read/write latency on a degraded SAN controller, which causes the cluster service to evict the attached host node because of CSV heartbeat timeouts. The technical detail is that the heartbeat signals fail under load, leading to node eviction events.

My question : how can we adjust the SameSubnetDelay and SameSubnetThreshold parameters to better tolerate these latency spikes without risking cluster instability ?

Windows for business | Windows 365 Enterprise
0 comments
Answer accepted by question author
Hoang Le 4,580 Reputation points Independent Advisor
2026-09-04T09:57:14.3566667+00:00

Hello Quinn,

The parameters SameSubnetDelay and SameSubnetThreshold directly control how quickly the cluster reacts to missed heartbeats. By default, SameSubnetDelay is 1 second and SameSubnetThreshold is 5, meaning a node is evicted after 5 seconds of missed heartbeats. To tolerate SAN latency spikes, you can increase the delay or threshold, for example setting SameSubnetDelay=2000 (2 seconds) and SameSubnetThreshold=10, which gives a 20‑second window before eviction. This adjustment is done with cluster.exe /prop SameSubnetDelay=2000 and cluster.exe /prop SameSubnetThreshold=10, or via PowerShell Get-Cluster | Set-Cluster -SameSubnetDelay 2000 -SameSubnetThreshold 10.

Be cautious not to raise these values excessively, because longer thresholds mean the cluster will take more time to detect a genuine node failure, potentially delaying failover. The best practice is to increase them moderately to cover transient storage latency while still ensuring timely detection of real outages. After tuning, monitor System and FailoverClustering event logs to confirm that heartbeat failures are reduced without masking actual node failures.

If my answer is useful for you, please hit Accept the answer to support me.

Thank you,

HL.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-09-04T09:18:24.1466667+00:00

    Use a gradual, conservative increase and keep the timeout relationships valid.

    SameSubnetDelay controls how often heartbeats are sent, and SameSubnetThreshold controls how many missed heartbeats are allowed before the node is considered down. The effective same-subnet tolerance is:

    SameSubnetDelay × SameSubnetThreshold

    Examples from the documented defaults and recommendations:

    • A default of 1000 ms × 10 gives about 10 seconds before the node is removed.
    • For Azure SQL Server on Windows Server 2012 or later, Microsoft recommends relaxing to SameSubnetThreshold = 40 with SameSubnetDelay = 1 second, which gives about 40 seconds of tolerance.
    • For some Azure SAP WSFC scenarios in the same subnet, tested values are SameSubnetDelay = 2000 and SameSubnetThreshold = 15, which gives about 30 seconds of tolerance.

    Recommended approach:

    1. Fix the root cause first where possible. Increasing heartbeat values can stop evictions, but it can also mask the underlying SAN or network problem rather than resolve it.
    2. Increase values gradually, not aggressively. Microsoft guidance for Always On notes that increasing timeout values improves tolerance for transient issues but slows reaction to hard failures.
    3. Prefer increasing delay first, then threshold when making the cluster more tolerant. This increases the time between heartbeats and can reduce congestion while giving transient issues more time to clear.
    4. Do not set values below defaults. Lowering timeout values below default is not advised.
    5. Keep these relationships valid:
      • SameSubnetThreshold <= CrossSubnetThreshold
      • SameSubnetDelay <= CrossSubnetDelay

    A practical tuning path for same-subnet nodes is:

    • Start by checking current values:
    Get-Cluster | fl *subnet*
    • If current settings are near default and transient latency is causing evictions, first try a moderate increase such as:
    (Get-Cluster).SameSubnetDelay = 2000
(Get-Cluster).SameSubnetThreshold = 15

    Expected effect: about 30 seconds of same-subnet tolerance.

    • If that is still not sufficient and the environment can tolerate slower failover, move toward the more relaxed pattern used for Azure SQL Server on Windows Server 2012-2019:
    (Get-Cluster).SameSubnetThreshold = 40

    If SameSubnetDelay remains 1000, expected effect is about 40 seconds of tolerance.

    • Verify the change:
    Get-Cluster | fl *subnet*

    Expected output should show the updated subnet values.

    Important tradeoff: higher values reduce false evictions during latency spikes, but they also delay failover during real node failures. That is the main stability risk. For that reason, changes should be incremental and based on how much additional outage detection time the workload can tolerate.

    Also note that one troubleshooting article explicitly states that increasing these values to the maximum may make node removal events go away, but only masks the problem. The only real need for substantially higher values is when latency is inherent, such as multi-site deployments.

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.