Monitor your Ethereum and Solana RPC endpoints

What a healthy RPC endpoint actually looks like

Before you can monitor for problems, you need to know what good looks like. A well-performing Ethereum or Solana RPC endpoint should hit these baselines:

These are not aspirational targets. They are the minimum bar for a production blockchain application. If your RPC endpoint drifts outside these numbers, your users experience it as broken — even if the endpoint is technically "up."

Managed providers promise 99.9% uptime — trust but verify

Alchemy, Infura, QuickNode, and Chainstack all commit to SLAs in the 99.9% to 99.99% range. That sounds excellent until you realize 99.9% still allows 8.7 hours of downtime per year — and the SLA only covers total outages, not degraded performance.

In practice, managed RPC providers fail in ways that do not count against their SLA. Latency spikes from 50ms to 5 seconds? Not an outage. Rate limiting your requests because you hit a tier limit? Not an outage. Returning stale block data because their node cluster has an internal sync issue? Technically not an outage.

Your DeFi trading bot does not care about the distinction. If eth_blockNumber returns a value that is 3 blocks behind the chain tip, your price oracle is showing 36-second-old data. In crypto markets, that is an eternity.

You need your own monitoring that checks what your application actually experiences — not what the provider's status page reports.

Self-hosted nodes: sync status, block lag, and disk usage

Running your own Geth, Erigon, or Solana validator gives you full control — and full responsibility. Self-hosted nodes have failure modes that managed providers abstract away:

The insidious part: your node's HTTP server stays up through all of these failures. A simple health check returns 200 OK. Only checking the actual RPC response content reveals the problem.

Block lag: the silent killer of DeFi applications

Block lag deserves its own section because it is the most common and most damaging RPC failure mode. Your endpoint is up. It responds quickly. It returns valid JSON. But the block number it reports is behind the chain tip.

For a DEX aggregator, block lag means your quoted prices are stale. A user submits a swap expecting one rate and gets a worse one — or the transaction reverts entirely because the state changed. For a lending protocol, block lag means liquidation bots see stale collateral ratios and either miss liquidations or trigger incorrect ones.

# Check block lag with eth_blockNumber
$ curl -X POST https://your-rpc-endpoint.com \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

→ {"jsonrpc":"2.0","id":1,"result":"0x13A22F7"}
# Convert hex to decimal: 20,586,231
# Compare against a reference (Etherscan, another provider)
# If your node returns 20,586,228 — you are 3 blocks behind
# That is 36 seconds of stale data on Ethereum

On Solana, block lag is measured in slots. At 400ms per slot, even 10 slots of lag means 4 seconds of stale state — enough to cause failed transactions on high-frequency trading protocols.

Rate limiting and WebSocket disconnects

Two more failure modes that do not show up on provider status pages:

WebSocket monitoring is harder to automate, but you can monitor the HTTP RPC endpoint as a proxy. If the HTTP endpoint is degraded, the WebSocket connection is almost certainly affected too. For critical WebSocket feeds, also monitor a health endpoint in your own application that reports whether the WebSocket subscription is active and receiving data.

How to monitor: HTTP checks with JSON-RPC validation

The simplest effective RPC monitor is an HTTP POST to your endpoint that calls eth_blockNumber (Ethereum) or getSlot (Solana) and verifies the response:

# Ethereum — verify the endpoint returns a block number
POST https://your-rpc-endpoint.com
Content-Type: application/json

{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}

# Expected: {"jsonrpc":"2.0","id":1,"result":"0x..."}
# Keyword match on "result" confirms a valid JSON-RPC response
# If the endpoint returns an error, "result" is absent

# Solana — verify the endpoint returns a slot number
POST https://your-solana-rpc.com
Content-Type: application/json

{"jsonrpc":"2.0","method":"getSlot","params":[],"id":1}

# Expected: {"jsonrpc":"2.0","id":1,"result":123456789}
# Same principle: keyword match on "result"

This catches the most common failures: endpoint down, endpoint returning errors, endpoint rate limiting you (429 response), and endpoint returning malformed responses. It does not catch block lag on its own — for that, you would need to compare the returned block number against a reference — but it catches the failures that matter most.

For deeper monitoring, expose a /health endpoint in your own application that checks block lag against a second RPC provider. If the difference exceeds your threshold, the health check fails and your monitor catches it.

How to monitor blockchain RPC with Uptrack

Uptrack's HTTP endpoint monitoring maps directly to RPC health checking. Here is how to set it up:

Managed RPC provider (Alchemy, Infura, QuickNode)

Create an HTTP monitor pointing at your provider's RPC URL. Set the method to POST, add the eth_blockNumber JSON-RPC payload as the request body, and add a keyword match rule for "result" in the response. Set the interval to 30 seconds. If your provider goes down, starts rate limiting, or returns errors, the keyword check fails and you get alerted within 90 seconds via Slack, Discord, or email.

Self-hosted Geth or Erigon

Same approach as managed providers, but also add a second monitor for your application's custom health endpoint that checks sync status and block lag. If eth_syncing returns anything other than false, your node is still catching up and should not serve production traffic.

Solana RPC

Monitor with a getSlot or getHealth JSON-RPC call. The getHealth method is particularly useful — it returns "ok" when the node is within an acceptable slot range of the cluster and an error if it has fallen behind. Keyword match on "ok" for a clean health signal.

Multi-chain applications

If your app uses Ethereum, Solana, and an L2 like Arbitrum or Base, create a monitor for each chain's RPC endpoint. Uptrack's free tier gives you 50 monitors — enough to cover multiple chains, multiple providers per chain for redundancy, and your own application health endpoints on top.

Why 30-second checks matter for blockchain

Ethereum produces a block every 12 seconds. Solana produces a slot every 400 milliseconds. Blockchain infrastructure moves fast, and failures compound quickly.

With a 5-minute monitoring interval, a rate-limiting spike that lasts 3 minutes is invisible. Your trading bot failed 200 transactions, your users saw errors, and your monitoring dashboard shows 100% uptime. With 30-second checks, you catch the degradation within one interval, get alerted, and can switch to a backup provider or escalate with your current one.

For crypto infrastructure specifically, the cost of missed failures is measured in money — real financial losses from stale prices, failed transactions, and missed liquidations. Catching an RPC outage 4 minutes earlier is not a nice-to-have. It is the difference between a minor incident and a material loss.