Uptime monitoring for web3 and crypto services

Q: How do you detect a lagging RPC node?

Assert on a freshness signal such as block height in the response content, so a node that answers but trails the chain is flagged rather than counted as healthy.

Q: Why is a 200 status not enough for a crypto endpoint?

Because a node can return a successful response while serving stale data after falling behind the chain. Only a content assertion on freshness — like an advancing block height — distinguishes a current node from a lagging one.

Q: How do I monitor an indexer that falls behind after a reorg?

Heartbeat the indexing job so a stalled or failed run alerts, and assert on a freshness field in the data it serves. Reorgs cause silent drift, so watching both the job and the output catches it.

Q: How do I start with uptime monitoring for web3 and crypto services?

Pick the two or three production surfaces where web3 infrastructure teams feel an outage first, attach one check to each, and route the alerts to a single owner before expanding coverage.

Practical monitoring workflows for web3 infrastructure teams.

Web3 and crypto uptime monitoring for RPC nodes, indexers, and wallet endpoints — assert on block height and freshness so a node that answers but serves stale data is caught.

What this team needs to watch

Web3 services depend on infrastructure that never sleeps: RPC nodes, indexers, and wallet endpoints that users hit around the clock. The signal is whether those endpoints answer correctly and in sync, because a lagging node returns stale answers that look fine.

A responsive RPC node can still be serving stale data.
Indexers fall behind silently after a reorg.
Assert on block height or a freshness field, not just a 200.

Freshness is the real uptime signal

In web3, "the node answered" and "the node is correct" are different questions, and only the second one matters to users. An RPC node can respond instantly with stale data after falling behind the chain, and an indexer can quietly drift after a reorg without ever erroring. A status-only check is blind to both. Assert on a freshness signal in the response — a plausible, advancing block height or a timestamp field — so a lagging node fails the check instead of passing it. Indexing jobs that rebuild state need a heartbeat so a run that falls behind or dies is caught, and every public hostname needs a certificate check, since wallet and API clients tend to fail hard on an expired certificate rather than warn.

How Sandglass covers it

Run HTTP checks on the RPC and API endpoints, content checks that assert a sane block height or response field, and SSL certificate checks on public hostnames. Heartbeat the indexing jobs that fall behind quietly when a chain reorganizes.

Group checks by service, environment, or client so production alerts stay separate from staging noise.
Combine HTTP, ping, TCP, content, and SSL certificate checks to match each failure mode you care about.
Add heartbeat checks for scheduled jobs that no customer watches directly but everyone depends on.

Where teams get it wrong

A node that responds is not always a node that is current. Without asserting on freshness, a check stays green while users receive outdated chain data.

Implementation checklist

Step 1: Map the customer-facing surfaces

List the endpoints, jobs, and components where an outage would reach the people you serve. Keep the first pass to production.

Step 2: Pick one check per failure mode

Use HTTP or content checks for web surfaces, TCP for raw ports, SSL certificate checks for HTTPS expiry, and heartbeats for scheduled work.

Step 3: Separate environments with groups

Put production, staging, and per-client checks in their own groups so routing and noise stay under control.

Step 4: Tune after the first week

Adjust intervals and retry counts once real data shows which alerts were signal and which were noise.

Frequently Asked Questions

How do you detect a lagging RPC node?

Why is a 200 status not enough for a crypto endpoint?

How do I monitor an indexer that falls behind after a reorg?

How do I start with uptime monitoring for web3 and crypto services?

Monitor uptime monitoring for web3 and crypto services with Sandglass

Start free

Free plan, no credit card required.