RPC Endpoint Monitoring: Availability, Freshness and Correctness

A successful connection is not a healthy endpoint

An RPC endpoint can respond quickly while serving stale data. It can also return a valid latest-block response while failing the historical queries your application needs. Monitoring should establish whether the endpoint can serve your workload, not merely whether its URL responds.

Separate four signals: availability, data freshness, response correctness and latency. Track them per endpoint and method. Otherwise, thousands of successful lightweight calls can hide failures in the smaller set of requests that actually determine whether deposits are detected or an indexer catches up.

Check the response and the chain

For JSON-RPC calls, inspect the response body as well as the HTTP status. Validate the response ID, distinguish result from error, and check the method-specific result format. An HTTP 200 response can still carry an RPC error. The JSON-RPC specification defines the response envelope; it does not establish whether the returned blockchain data is current.

On Ethereum, use eth_chainId to check network identity, eth_blockNumber to observe progress, and eth_syncing as an additional synchronization signal. These methods are documented in the Ethereum JSON-RPC API. A node reporting that it is not syncing is not, by itself, proof that its data meets your application's freshness requirement.

Compare block progress with an independent reference and observe how long the difference persists. A single comparison can catch nodes between block updates. Set alert thresholds from your application's tolerance and the network's behavior, rather than copying a universal number of blocks. If independent endpoints all stop advancing, investigate the chain before treating the event as one provider's failure.

Test the data your application depends on

Keep a small set of known-answer checks. For an archive workload, that could include a balance at a specific finalized historical block. For a deposit processor, it could include a known transaction receipt. Verify the expected chain and block identity when establishing these fixtures. Our archive-node guide explains why a current-state check cannot demonstrate historical coverage.

Run both a lightweight probe and a representative application query. Keep synthetic traffic bounded: a monitoring job should not continuously repeat your most expensive backfill. Record request duration, outcome, RPC error code and endpoint label. Do not put credentials or sensitive request bodies into logs.

Monitor WebSocket subscriptions separately. Geth subscriptions are tied to their connection and do not replay all missed historical events after reconnection. Track disconnects, subscription recovery and the application's processed-block checkpoint, following the behavior described in the Geth subscription documentation.

Turn alerts into operating decisions

Every alert should identify the affected workload and the next check. An unavailable endpoint, a lagging node and missing historical data need different responses. Probe from your application's region and, where practical, a second location to distinguish local connectivity problems from endpoint failures. Use these signals in your RPC failover policy, and keep continuous health checks distinct from workload latency benchmarks.

When scoping dedicated RPC infrastructure with DTEAM, include the methods, history and freshness targets your monitoring must cover. Agree monitoring responsibilities and escalation arrangements for the deployment. Send us your network and workload to plan a dedicated node around those requirements, including networks not currently listed on our site.