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.
Some chains don’t expose a reliable sync percentage. When one isn’t available, Novacula shows the sync as elapsed time behind the chain head instead — for example 18 minutes behind, 2 hours 15 minutes behind, or Less than a minute behind — alongside an indeterminate syncing indicator, and reads Up to date once the node has caught up. A node that reports nothing usable reads Sync status unavailable. This wording is the same everywhere sync is shown — the node lists, a node’s Overview, this tab, and the dashboard.
A node that has just started, and is syncing but hasn’t reported any height or progress yet, reads Starting sync… with the indeterminate indicator rather than a misleading 0% — it switches to a real percentage or time-behind as soon as the first height or progress arrives. A genuine zero on a node that isn’t syncing still shows as 0%.
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. Requests that carry no JSON-RPC method are grouped under Requests without method. A method name gets its own row only once a request authenticated with a key has called it — a pool client key or the node’s RPC key; each pool (or standalone node) tracks up to 64 names, and an executor about 1,024 across all of them; anything else reads
(other). So a pool or node that has served only unauthenticated callers shows(other)until a key is used on it.
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. CPU, memory, and disk usage are charted over the shared time range like the other Telemetry metrics — not just the latest figure. 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 tometrics.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.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.