> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tape.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Telemetry & Metrics

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](/protocol/node-setup/storage-node#metrics-and-health) and [gateway](/protocol/node-setup/gateway#metrics).

## 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`.

```yaml theme={null}
# prometheus scrape config
- job_name: tape-node
  metrics_path: /v1/metrics
  static_configs:
    - targets: ["node.example.com:3000"]  # your node's HTTP listener
```

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