How to Monitor RPC Endpoint Latency and Health

13 October 2026

Monitor nodes/rpc-endpoint-basics/">RPC endpoint latency and health by sending regular, low-cost JSON-RPC calls from a server in the same region as your application, tracking response times and error codes over time, and setting alerts for thresholds that matter to your specific use case. The goal is to catch problems before they become user-facing failures, and to know which provider is actually at fault when something breaks.

This page assumes you already know what an RPC endpoint is, how to read its URL, and how failover works. Here, you are learning how to measure the thing you are relying on.

What "Health" Means for an RPC Endpoint

A healthy RPC endpoint is not the same as a healthy website. You are not checking for a 200 OK. You are checking for three things:

1. Latency - how long a request takes, measured in milliseconds.
2. Correctness - does the response contain valid data, or an error?
3. Freshness - is the node synced to the latest block, or is it stuck?

Each matters differently. A node can respond in 50ms and still be useless if it is returning stale data from a chain 200 blocks behind. A node can be perfectly synced and still fail you if it is rate-limiting your IP after three requests.

The minimum viable monitor

You do not need a monitoring service to start. A simple script on a cron job, or a serverless function, can do the job. Here is the pattern:

1. Pick a method that is cheap and reliable. eth_blockNumber is the standard choice. It returns the latest block number and costs almost nothing in compute units.
2. Send it every 30 to 60 seconds from a machine that is geographically close to your application server. If your app runs in us-east-1, monitor from us-east-1. You are measuring the path your users actually experience, not the distance from your laptop to the internet.
3. Record the response time, the HTTP status code, and the block number returned.
4. Store these values somewhere you can graph. A simple time-series database like Prometheus, or even a CSV file, is enough to start.

Do not send the request from the same machine that runs the node you are monitoring. That tests the node, but not the network path to it. If your app is in the cloud, the network path is half the problem.

What to Track

Track latency as a distribution, not just an average. A node with a 2-second average might actually be failing half the time with 4-second responses and succeeding the other half with 100ms responses. Use percentiles: the 95th percentile (p95) and 99th percentile (p99) will tell you more than the mean.

Track error codes as a percentage of total requests. A 0.5% failure rate may be fine for a wallet. It is not fine for a trading bot. The right threshold depends on your application, so start with the failure rate of your own past week and set an alert at 2x that baseline.

Track the block number from eth_blockNumber and compare it to a known-good source. You can use a public explorer or a second provider you trust. If your monitored endpoint falls behind by more than 10 blocks, that is a health problem even if latency is perfect.

Setting Up a Basic Health Check with curl

For a quick, manual check, curl is enough:

curl -s -w "HTTP %{http_code}, time %{time_total}s\n" \
 -X POST https://your-rpc-endpoint.example.com \
 -H "Content-Type: application/json" \
 --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

The -w flag prints the HTTP status and total time. You will see something like:

HTTP 200, time 0.234s

But you also need the response body to check the block number. Use jq to extract it:

curl -s -X POST https://your-rpc-endpoint.example.com \
 -H "Content-Type: application/json" \
 --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
 | jq -r '.result'

That gives you a hex block number. Convert it to decimal with printf '%d\n' 0x$(...) if you need to read it.

When latency spikes are not the node's fault

Before you blame the provider, check your own network. A node can be perfectly healthy while your monitoring script reports 3-second responses because your cloud provider is having a routing issue. That is why the monitoring location matters. If you see a problem, run the same test from a second location. If both locations show the same spike, it is likely the endpoint. If only one does, it is your network path.

Also check whether you are being rate-limited. A 429 error means the node is healthy but refusing to serve you. That is a health problem for your use case, but not a node failure. The fix is either a different provider or a dedicated node.

What to do when something fails

If you see high latency, first check the block number. A syncing node will often have high latency because it is busy catching up. If the block number is current and latency is still high, the issue is likely CPU or network contention on the node host.

If you see connection refused or timeouts, check whether the endpoint is up at all. ping will not tell you much, but a simple nc -zv <host> <port> will tell you if the TCP port is open. If the port is open but requests time out, the node process may be hung or the provider may be blocking your IP.

For a 403 error, your request is being rejected by a firewall or load balancer, usually because of a missing or wrong User-Agent header. For a 429, you have hit a rate limit.

When to run your own node

Monitoring third-party endpoints is necessary, but it is a stopgap. At some point, the question becomes whether you should stop relying on third parties altogether and run your own node. That is a bigger decision, covered elsewhere on this site, but the monitoring data you collect will help you make it.

If your monitoring shows that your primary provider fails or degrades more than a few times a month, and you are making enough requests that rate limits are a constant problem, the cost of running your own node may be lower than the cost of the downtime you are experiencing.

A simple alerting rule to start

Start with one alert. Not five. One.

• Every 60 seconds, send eth_blockNumber to the endpoint.
• If the request takes longer than 2 seconds, or returns an error, or returns a block number older than 30 seconds from the current head, mark it as unhealthy.
• If it is unhealthy for 3 consecutive checks, page someone.

The exact values do not matter yet. What matters is that you are collecting data. After a week, look at the numbers. Adjust the thresholds to be slightly worse than your normal p95. Then add a second alert for the second provider, and compare.

You will learn more in a week of real traffic than in a month of reading about it.

Back to rpc & nodes