Node Health

Overview

Node health summarizes whether a node is operating within acceptable technical and protocol limits. Core dimensions include chain-head and finalized-block lag, peer count, database status, CPU and memory pressure, disk capacity, RPC errors, and software version. Validators add missed proposals, voting performance, and key or slashing-protection status.

Health differs from Node Availability. An available node can answer requests but still be unhealthy because it is stale, overloaded, or connected to too few peers. Conversely, a node under maintenance may be temporarily unavailable without corruption. Operators should define states such as healthy, degraded, syncing, draining, and failed rather than forcing every condition into a binary result.

Protocol-aware checks are essential. The node should agree with independent references on chain ID, finalized root, and recent block data. A fast RPC response from the wrong fork is dangerous. Monitoring should also detect abnormal reorg depth, repeated peer churn, time drift, database compaction delays, and storage growth that can predict future failure.

Health signals should control traffic and escalation. Load balancers can remove degraded RPC nodes, but validators may require manual review before failover to avoid double signing. Dashboards should preserve historical context so teams can distinguish a transient spike from progressive deterioration. A good health model supports preventive maintenance and safer Node Recovery rather than reacting only after complete outage.

Node Health should be evaluated against the target network’s actual rules, not a familiar label from another system. In this case, node health requires current and correct protocol behavior across synchronization, peers, storage, resources, and role-specific duties. The supporting evidence for Node Health should remain available for review, including the relevant block, transaction, state, or key records.