Pick a time range
Every chart on the Monitoring tab shares one time-range toggle in the top-right of the Telemetry section. Switch it to widen or narrow the window for every chart at once. Each chart also shows its latest value next to the title, so you can read the current number without hovering. If a node has just been deployed — or its clients expose no metrics endpoint — a section shows No metrics are available for this node yet. Give it a few minutes after the node starts reporting.Telemetry
The Telemetry section charts the core node-health metrics. A chart appears only for the metrics the node’s clients actually expose, so the exact set varies by chain and by the clients you chose:| Chart | What it shows |
|---|---|
| Block Height | Height of the latest block the node has imported. |
| Peers | Number of connected peers. A node stuck at zero peers is the most common cause of a stalled sync. |
| Chain Tip | The network’s latest known block, when the client reports it. Compare against Block Height to gauge how far behind the node is. |
| Finalized | Latest finalized block, on chains that expose finality. |
| Sync Progress | Percentage synced. Reaches ~100% once the node is caught up. |
| Sync Lag | How far behind the chain head the node is, in time (seconds). |
| Disk Read / Disk Write | Storage throughput in bytes/second. |
| Read IOPS / Write IOPS | Storage operations per second. |
| Snapshot Download | Download progress while a node is bootstrapping from a snapshot — bytes downloaded, speed, attempts, and resumes. Appears only during snapshot bootstrap. |
RPC Usage
The RPC Usage section charts the traffic your apps send to the node’s RPC endpoint:- Requests — requests per second.
- Error Rate — percentage of requests that failed.
- Latency — average response time, in milliseconds.
- Request Bytes / Response Bytes — RPC traffic in bytes/second.
- Top RPC Methods — a table of the busiest methods with their request count and error rate, so you can see which calls dominate.
Resource Usage
The Resource Usage card shows both the capacity you allocated to the node when you deployed it — its CPU and Memory limits and declared Disk total — and the live utilisation the executor reports against it: how much CPU, memory, and disk the node is actually using. For multi-process nodes, usage is broken down per client, so you can see which role (for example an Ethereum execution vs. consensus client) is driving consumption. Memory is reported as the process tree’s actual physical memory (RSS), not the cgroup figure — so a database-heavy node isn’t shown as near-full just because the OS is using free RAM for file caches. On the Operator backend, disk usage comes from the node’s Kubernetes persistent volumes (PVCs), so the figure reflects real on-disk consumption of the data volume. Live figures read- until an executor reports them — give a freshly deployed node a few minutes, and on Kubernetes make sure the Operator can read pod metrics (see the note below).
Disk pressure is also surfaced through the Disk usage alert: when a node’s disk usage crosses its effective threshold (Default disk threshold, default 85%), the built-in alert fires. Alerting is coming soon — see Notifications.
Kubernetes pod metrics
On the Operator backend, per-client CPU and memory usage is read from the cluster’s metrics API. That requires metrics-server installed in the cluster and the Operator’s RBAC granting read access tometrics.k8s.io — both shipped in the updated operator chart. If usage stays - on Kubernetes, upgrade to the current chart and confirm metrics-server is running. See Provision on Kubernetes.
Chain Metrics
The Chain Metrics card summarises the node’s current lifecycle state — its reported status and message, latest block height, and sync progress. Additional per-chain values (for example a Bitcoin node’s difficulty, hash rate, or mempool size) aren’t surfaced here yet. When nothing has arrived, the card reads No chain-specific metrics have been reported yet.Query
When the fixed charts above aren’t enough, the node’s Query tab lets you run ad-hoc PromQL queries against that node’s own metrics and chart the result. Start from a recipe — a ready-made query scoped to this node — then edit it, or write your own from scratch. A label browser helps you insert label matchers without memorising them, and results are drawn as a multi-series chart. Use it for one-off questions the standard sections don’t answer; use the fixed sections above for the everyday view.How fresh is this?
Metrics are only as current as the node’s last report. The Overview tab’s Lifecycle panel shows Last Seen and a state badge — State current, State pending, or Not reported — so you can tell whether the figures reflect reality. If a node has gone quiet, treat its metrics as stale until it reports again.Where this isn’t
- Process logs live in the Logs tab, not here. Use logs for “what is the client printing”; use Monitoring for “how much / how often / how slow”.
- Notifications — being paged when a metric crosses a line (node down, disk full) is coming soon — see Notifications.
Related
- Notifications — turn metrics into outbound alerts and tune thresholds per node (coming soon).
- Node logs — read a node’s process output.