Skip to main content
Open a node, then select the Monitoring tab to see its live metrics as charts over a time window you choose. Use this to answer the everyday questions: is the node synced, does it have peers, is it serving RPC, and is it running out of CPU, memory, or disk? For an at-a-glance snapshot instead, the node’s Overview tab shows the latest value of the headline metrics — block height and peers — without charts.

​
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: For multi-process nodes (an Ethereum execution-layer client plus a consensus-layer client), each process reports its own metrics, so you may see, for example, separate height and peer charts per role.

​
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.
When there’s no RPC traffic in the selected window, the section shows No RPC traffic in this range.

​
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 Low host disk space alert preset: author a rule against it and you’re notified when a node’s disk usage crosses the threshold — see Alerts.

​
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 to metrics.k8s.io for both nodes and pods — all shipped in the current operator chart. If usage stays - on Kubernetes, helm upgrade to the current chart and confirm metrics-server is running. See Provision on Kubernetes. Cluster-level memory is reported alongside CPU: node memory capacity and allocatable from a cluster-wide node read, plus live workload usage — the Operator’s own pod and the node pods it manages — from a read scoped to its own namespace. See Cluster telemetry for the chart-level knobs. On the executor’s own Monitoring tab this surfaces as Memory used, given both as a percentage of allocatable cluster memory and in GiB. Read it as a cluster figure, not a host figure — and note that the CPU and disk charts beside it describe the Operator pod, not the cluster. This needs an Operator on release 0.1.11 or newer; an older Operator falls back to reporting its own pod’s memory.

​
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”.
  • Being paged when a metric crosses a line (node down, disk full) is configured under Alerts, not here.
  • Alerts — turn these metrics into outbound notifications on Slack, Telegram, Teams, or a webhook.
  • Incidents — the feed of firing and resolved occurrences.
  • Node logs — read a node’s process output.