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: 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.

Uptime monitoring for web3 and crypto services with HTTP, ping, TCP, content, SSL certificate, and heartbeat checks, alerts, and public status pages in one Sandglass workspace.

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 and across regions. 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.

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?

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.