Skip to main content
Nodes and gateways built with the metrics cargo feature expose Prometheus-compatible metrics. You scrape those into your own monitoring, and the network runs fleet-wide dashboards on top, covered below. Alert guidance lives with each setup guide: storage node and gateway.

​
The endpoint

Metrics are opt-in at build time: the binary must be compiled with the metrics cargo feature (the repository’s make targets do this). A metrics build serves /v1/metrics on the node’s regular HTTP listener; there is no separate metrics port. Serving is enabled unless you set metrics.enabled: false in node.yaml.

​
Node metrics

  • Chain ingest: tape_node_ingest_tip_slot and tape_node_ingest_lag_slots (how far behind the tip the node’s view is), tape_node_blocks_processed_total, tape_node_replay_events_total, tape_node_epoch_transitions_total.
  • Spool sync: tape_node_spool_bytes_total{op, stage} for pipeline traffic when spools move, tape_node_epoch_synced_groups for per-epoch progress, tape_node_repair_escalations_total when recovery has to escalate.
  • Storage fullness: tape_store_disk_used_bytes against tape_store_disk_available_bytes, plus tape_node_shards_owned for how many spools the node currently holds.
  • Committee state: tape_node_status (1 when active in the committee), tape_node_epoch, tape_node_epoch_phase, tape_node_committee_size, tape_node_groups_total, tape_node_peers_total, tape_node_peer_capacity.
  • Peer serving: tape_node_requests_total, tape_node_bytes_uploaded_total, tape_node_bytes_downloaded_total.
  • Queue health: tape_node_channel_depth for per-feature backlog inside the node.
A challenge pass-rate family will land with the challenge protocol; rewards do not depend on it yet.

​
Gateway metrics

  • Request latency and throughput: tape_http_request_duration_seconds{route, method, status_class} (error rates come from status_class) and tape_http_response_bytes_total{route}, shared with the node listener.
  • Decode pipeline: tape_gw_decode_duration_seconds{kind}, tape_gw_decode_total{result}, tape_gw_decode_slices_total{outcome} for per-slice fetch outcomes, tape_gw_decode_output_bytes_total.
  • Slice cache: tape_gw_cache_requests_total{result} for hit rate, tape_gw_cache_evicted_total for churn.

​
Fleet observability

Your node’s metrics are also part of how the network sees itself. Every node serves a structured health board at /v1/observe/board; a node with metrics.aggregate_peers: true (off by default, meant for nodes backing a dashboard) also probes its committee peers on an interval and serves the aggregate at /v1/observe/network, with /v1/observe/peer/{addr}/board proxying any single peer. Dashboards built on those routes show sync status, capacity, and version spread across the committee, answering the first question you’ll have when something looks wrong on your machine: is this me, or is this everyone?

​
Reading them together

The pairing that matters for any operator: chain-sync lag (is my view current?) against serving metrics (am I answering?). A process that responds quickly from stale state is failing; it’s serving yesterday’s network.