Diagnose an Ethereum node whose latest block has stopped moving
An execution RPC endpoint can answer requests while its view of the chain falls behind. Compare its sync response with its block timestamps before redirecting traffic to it.
Take two observations
Send both requests to the same backend. For a node that exposes HTTP RPC locally, run these commands, record the time, then repeat after a minute. If the endpoint balances multiple machines, select a specific backend for diagnosis.
curl -sS -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","id":1,"method":"eth_syncing","params":[]}' http://127.0.0.1:8545
curl -sS -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","id":2,"method":"eth_getBlockByNumber","params":["latest",false]}' http://127.0.0.1:8545
Compare the block number, hash and timestamp across samples. Convert the hexadecimal timestamp to Unix seconds before comparing it to the observation time. A brief pause between blocks is normal. If the timestamp is old and the hash stays fixed while a trusted mainnet peer advances, this backend is stale.
Follow the execution and consensus clients
An object returned by eth_syncing supplies progress information. Compare fields over time and inspect local logs for the active stage. A false response says the client reports no sync in progress. Geth depends on its consensus client for a target head, so check the consensus client’s peers and head, then inspect both clients’ logs for Engine API authentication or connection errors. Retest both RPC reads after restoring the connection. geth.ethereum.org How Geth receives its sync target