A node process that is running is not necessarily a node that is synced. This is the single most common false positive in node operations. The process is up, the logs are moving, the dashboard is green, and yet the node is hundreds of thousands of blocks behind the chain head, or synced on the execution side while its consensus client is still catching up. Serving traffic from that node returns stale data, misses new blocks, or fails outright. Every node check should therefore answer two separate questions: is the process healthy, and is the data current?
On a post-Merge Ethereum node there are two clients to check, not one. The execution client, such as Geth, processes transactions and holds state. The consensus client, such as Lighthouse, Prysm, or Teku, follows the beacon chain. Both must be synced before the node is usable. Checking only one is how operators declare victory a day early. The checks below use Geth and a generic consensus client as examples, but the pattern - local height versus network height, for each client - applies to every chain.
Execution client: eth_syncing and block height
The most direct execution check is the eth_syncing method. Send a JSON-RPC request to your local endpoint, for example with curl to http://localhost:8545, asking for eth_syncing with no parameters. If the node is fully synced, the result is false - literally the JSON value false, not an empty object. If the node is still syncing, the result is an object with currentBlock and highestBlock, and often startingBlock. That object is your progress report: currentBlock is where you are, highestBlock is where the network is, and the gap between them is the work remaining.
Do not read a single eth_syncing result and stop. Watch it over minutes, not seconds. A healthy syncing node shows currentBlock climbing steadily. A stuck node shows the same currentBlock across several checks, or a highestBlock that keeps moving away. Also compare against an independent source: a public block explorer or a second node you trust. If your node reports a highestBlock far below the explorer head, your peers may be stale or your node may be following a wrong fork. Height alone never proves correctness, but height that disagrees with the network is always a warning.
Consensus client: the second half of synced
The consensus check is a separate API call. Most consensus clients expose a syncing endpoint, commonly GET /eth/v1/node/syncing on the beacon API port, which returns whether the beacon node is syncing, its head slot, and its sync distance. A node is only fully synced when both the execution and consensus sides report synced. An execution client can report eth_syncing as false while the consensus client is still behind, because the execution client has processed everything the consensus client has given it so far - which is not the same as everything the network has produced.
Logs confirm what the APIs claim. A syncing consensus client logs regular syncing progress with slot numbers. A synced one logs steady new blocks at the expected slot interval, roughly every 12 seconds on Ethereum, with no long gaps. A node that logs blocks in bursts followed by silence may be losing peers or struggling with disk speed. Read the last few minutes of logs, not just the last line: a single recent block proves the node was alive a moment ago, not that it is keeping up.
Five traps that fake a synced node
First, checkpoint sync can make a node look synced fast while it still verifies history in the background. Treat checkpoint-synced nodes as provisional until both clients report synced and stay synced for an hour. Second, a node with no peers, or only a handful of bad peers, can report a highestBlock that is simply the tallest block its peers know about, which may be old. Check peer count alongside height: a healthy node has many peers, and a node with zero peers has no way to know the real head. Third, disk-full nodes stop advancing silently. Height freezes, logs fill with write errors, and the process stays up. Check disk headroom before declaring a sync problem a network problem.
Fourth, clock drift breaks consensus participation even on a synced node. Validators and consensus clients depend on accurate time, and a clock off by seconds causes missed attestations. Run NTP, check the offset, and alert on drift. Fifth, a node that just restarted may report synced from cached state and then fall behind under load, because its disk cannot keep up with new blocks. The fix is the same in every case: check height, peers, disk, clock, and logs together, on a schedule, not one signal in isolation.
Turn the check into a routine
A usable sync routine has four steps and takes two minutes. One, query eth_syncing and record currentBlock and highestBlock. Two, query the consensus syncing endpoint and record head slot and sync distance. Three, compare both against an independent explorer head. Four, check peer count, disk usage, and the last lines of both clients logs. Automate the same four steps with a script and an alert: alert when the gap grows for more than ten minutes, when peer count drops below a threshold, or when disk passes 80 percent. A validator that goes out of sync at night and is discovered in the morning has already lost rewards and trust, and a silent sync failure is worse than a loud crash because nothing pages you.
When a node will not sync, work in order: peers, disk, clock, then client version and configuration. Restarting is not a diagnosis, and restarting repeatedly can make a disk problem worse. If you are setting up monitoring for the first time, or if sync problems keep returning after restarts, blockchain node setup and DevOps node operations cover sync strategy, monitoring, and alerting, starting with a free infra audit. Bring the output of eth_syncing, the consensus syncing endpoint, peer count, and disk usage from the same minute: those four numbers let an operator diagnose most sync failures without guessing.
Disclaimer: This post is educational only, not financial advice. Figures are listing or project data as of 2026-10-30 and may change - always confirm version numbers, requirements, and dates in the official docs before acting on them.