Monitoring

frost-node exposes Prometheus metrics on metrics_listen (9184 by default). Keep it bound to localhost and scrape it locally.

curl -s http://127.0.0.1:9184/metrics

What matters most

Ordered by how badly you want to know.

The node halted

Frost is fail-stop by design. It halts on execution-layer errors, on a journal hash mismatch, and on checkpoint-chain staleness. Each of these is a case where continuing would risk building a different chain than the network.

Alert on the process exiting, and alert on restart loops separately. A node that restarts repeatedly is not self-healing, it is telling you something.

A halt on hash mismatch is the most serious signal a Frost node can produce. It means a rebuild did not reproduce the recorded block hash — nondeterministic execution. Do not simply restart. Verify the binary against the recorded digest for the pinned commit, and confirm the consensus parameters compiled into it are the network’s. See Bootstrap and recovery.

Disk

This is the resource that will actually run out.

Post-quantum signatures make history growth substantial: under sustained load the execution layer grows on the order of gigabytes per day, and the consensus layer several times faster. A node that fills its disk stops.

Alert on free space and on growth rate, not just a static threshold. A sudden change in growth rate usually means the retention window is not pruning what you think it is.

Checkpoint freshness

Checkpoints certify the block-key schedule. If the checkpoint chain stops advancing, the node alarms and then halts.

Alert on the alarm, not the halt — by the time it halts you have lost the window to act. Freshness problems are usually network-wide rather than local, so check whether checkpoints are being certified at all before assuming your node is at fault.

Head progress

Compare your head against another node:

# yours
curl -s http://127.0.0.1:8645 -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

# the public network
curl -s https://rpc.frostfi.net -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Blocks are one second apart, so a lag of more than a few blocks is meaningful.

Better still, compare a block hash at a height you have both passed. Identical hashes prove your node is reproducing the network’s chain exactly; matching heights only prove you are both counting.

Block key expiry

Block keys have expiring validity windows. A validator whose key expires cannot propose.

Rotation is routine and scheduled, but alert on time-to-expiry rather than relying on the schedule having run. Rotate well before the window closes.

Also worth watching

Consensus participation — whether your validator is contributing to the DAG and whether its blocks are being referenced by others. A validator that is technically alive but not participating is a quiet failure.

Ingress rejection rate — a spike usually means either an abusive client or a broken one. The rejection reasons distinguish them.

Retention floors — pruning is clamped by consumer progress, the latest certified checkpoint, the durable-execution floor, and the verified-upload floor on archiving hosts. If pruning is not keeping up with disk growth, one of these floors is holding it back, and that is the thing to investigate rather than the window setting.

Archive upload progress, on hosts that export to cold storage. Data may not be pruned until it has been uploaded and hash-verified, so stalled uploads become stalled pruning become a full disk.

Health checks

A simple liveness check:

curl -sf http://127.0.0.1:8645 -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \
  >/dev/null || exit 1

For readiness, additionally check that the head has advanced since the last probe. A node that responds but is not progressing is not serving anyone.

What not to alert on

Individual transaction rejections. The ingress refuses invalid submissions by design, and that is the system working.

Occasional peer disconnects. The consensus DAG tolerates them; that is the point of a DAG.

Head briefly lagging by a block or two. Blocks are one second apart. Set thresholds accordingly, or you will train yourself to ignore the alerts that matter.