Guide

Knowing your node is healthy

What to measure on a node you run — and what to measure on a provider you do not — including the four checks this platform performs on every endpoint, written out so you can run them yourself.

ObservabilityAll three chainsUpdated 16 August 2026

The four questions, in order

This platform asks four things of every endpoint on every measurement, and they are in this order because each one is meaningless until the one before it passes. They work just as well against a node you run, and the whole method is published in full so it can be copied rather than guessed at.

Did it answer at all?
Connection, TLS, HTTP status, a body. This is the only question most monitoring asks, and it is the one least likely to be the problem.
Is the answer the right shape?
A JSON-RPC error is not an answer. Neither is a result of the wrong type, nor an empty string where a block number belongs. A gateway returning HTML with a 200 status will pass step one indefinitely.
Is it the right chain?
Compare the reported network against the one you meant. Sounds paranoid until the afternoon a configuration change points production at a testnet and every check stays green because a testnet is extremely available.
Is it current?
The one that matters and the one almost nobody implements. Compare the head this node reports against a reference — the highest plausible head among several sources at the same instant — and record how far behind it is. A node three blocks behind is fast, healthy, correct and wrong.

The fourth check, drawn. A node compared only against itself reports full health the entire time it is falling behind, because from inside, it is healthy — the gap only exists relative to something else.

On a node you run

Every serious client exposes Prometheus metrics; turn them on at start-up, because the version of this you build after your first incident is always worse than the one you built before it. Bind the metrics port to your monitoring network, not to the world.

# Geth: expose metrics on a private interface
geth --metrics --metrics.addr 127.0.0.1 --metrics.port 6060

The list worth scraping is shorter than the list available:

Distance from the head — the first alert you should build: Your node’s head against a reference that is not your node. A second node, a public endpoint, anything independent. Without an external reference a node that has stopped following the chain reports itself perfectly healthy, because from inside, it is.
Sync status: Explicitly, not inferred. A syncing node answers quickly with old state; if your load balancer does not know, it will happily send it traffic.
Peer count: Leading indicator for everything else. A node losing peers is a node about to fall behind, and it usually means a firewall or NAT change rather than anything about the chain.
Disk free, and the trend: Chain data grows monotonically. The alert is not a threshold, it is a projection: at this rate, this disk is full on this date.
Per-method latency and error rate: Aggregate latency across all methods is a number that describes nothing — a balance read and a log range are different jobs. Split by method or the expensive ones will hide inside the average of the cheap ones.
Consensus-client finality, if you run one: Distance between head and finalised. Growing means the chain is having a bad time, and it is worth distinguishing from your node having a bad time.

And from outside, where your users are

Everything above is the node’s opinion of itself. It cannot see a failed TLS handshake at your load balancer, a DNS record pointing somewhere wrong, or the fact that your node is superb and unreachable from the continent your users live on.

Call the real endpoint the way an application does — through the same DNS, the same proxy, the same TLS, with the same credentials. Anything you skip is a component nobody is monitoring.
Do it from more than one place. Latency is a property of a network path, so where a measurement was taken is part of the measurement — which is why the figures here are broken out by vantage point rather than averaged into one number that describes nowhere.
Compare against something. “p95 was 340ms” is not a finding. “p95 was 340ms while two other providers on the same chain from the same place were at 90ms” is.
Measure the provider you depend on too. If you use one, its outages are your outages, and you will want your own record of them rather than theirs.

Alerts, and the arithmetic behind them

Two rules that survive contact with a real on-call rotation: page for things a human must act on now, and make every threshold something you could defend to somebody woken by it.

Page on: Not answering. Behind the head by more than a few blocks for more than a couple of minutes. Disk projected full within days. Wrong chain, ever.
Graph, and review weekly: Latency percentiles per method, peer count, error class mix, cache hit rate, request mix by method. These tell you what to fix; none of them are worth a phone call at 3am.
Add hysteresis to everything: Fire above one threshold, clear below a lower one. Without it, anything hovering at the boundary alerts every few minutes, and an alert that fires constantly has been turned into a filtering rule in somebody’s inbox.

Measured here · two mistakes we made in our own status page, in public

Resolution. We first judged an endpoint’s live state against a 99.9% objective. The live window holds about seventy requests, so one failure is 98.6% — and a single local DNS failure marked two providers degraded. Seventy samples can distinguish “mostly working” from “mostly broken”, and cannot distinguish 99.9% from 100%. Asking them to produced a false claim about a company.

Double counting. We scaled error-budget consumption by how much of the window had been observed, on top of a budget that was already proportional to requests observed. One provider was published as having spent 4.9× its budget beside a 0.2× burn rate, from the same nine failures. Two figures on one row contradicting each other is the cheapest signal that one of them is wrong — and it only appeared against live data.

Both are worth stealing as rules. Match the threshold to what your sample size can support, and count an error budget in requests rather than in minutes: minutes imply continuous observation, and sampling is not that.

The dashboard that fits on one screen

If you build nothing else, build this. Four numbers per node, and one line of prose under them saying what “normal” is, so whoever is on call at 3am and has never seen this screen can tell.

Blocks behind the reference — the health check that catches the failure that looks like success.
Success rate over the last few minutes, with the request count beside it — the count is not decoration.
p95 latency for your three busiest methods — named, not aggregated.
Days of disk remaining at the current rate — the only capacity number that is ever urgent, expressed as the thing you actually want to know.

Everything else is for the investigation after the alert, and belongs on a second screen nobody looks at until then. If you want a worked example of these decisions being argued out against real data, the status pages here publish the thresholds, the sample counts and the reasoning alongside the numbers.