Node is behind by N slots

The RPC node has not caught up with the rest of the cluster. It is processing blocks from a slot that is behind the current network slot. Queries to this node may return stale data, and transactions sent through it may use expired blockhashes.

Common causes

1. Node under heavy load. Too many RPC requests, replay backlog, or insufficient hardware.
2. Network partition. The node temporarily lost connection to peers.
3. Node restarting. After a restart, nodes need time to catch up with the cluster.
4. Snapshot loading. The node is loading a snapshot and has not finished replaying slots.

How to fix

1. Check the node’s health with getHealth.
2. Compare the node’s slot with the cluster’s slot: query getSlot on your node and on a known-healthy node.
3. If your node is consistently behind, switch to a different RPC endpoint.
4. For self-hosted nodes: increase hardware resources (CPU, RAM, NVMe IOPS), optimize the node configuration, or use a fresh snapshot.

FAQ

How far behind is too far? A few slots (1-5) is normal and usually recovers quickly. More than 50 slots behind means the node is significantly lagging. More than 150 slots and blockhashes may expire before the node sees them.

Does this affect my transactions? Yes. A behind node may give you a blockhash it has not seen confirmed by the cluster, or it may be too slow to forward your transaction to the current leader.

How do I monitor node health? Poll getHealth periodically. A healthy response returns "ok". An unhealthy response includes the number of slots behind.

Updated: 2026-10-19