Metrics collected

Use this page as the reference for every OTLP metric name the ingestor accepts. The agent ships system metrics through an embedded OpenTelemetry collector: scraped every 30 seconds, streamed to the ingest endpoint over OTLP/HTTP.

There is no separate heartbeat; a server is considered live as long as its metrics keep arriving. Anything outside the accepted set below is dropped silently server-side.

Server detail with CPU, memory, load average, disk IO, network bandwidth, and disk usage charts
What the metrics become: live CPU, memory, load, disk IO, network, and disk usage charts on the server detail
Scrape interval
30 seconds
Dashboard lag
A few seconds after each scrape
Liveness
Derived from metric arrival
Transport
OTLP/HTTP, gzipped, on-disk queue

CPU

Processor metrics 3 metrics

system.cpu.utilizationpercent
Total CPU time spent in user, system, iowait, and other states, as a percentage of wall time. Per-state and per-CPU breakdowns are available as attributes.
system.cpu.load_average.{1m,5m,15m}scalar
1, 5, and 15-minute load averages. Read from /proc/loadavg on Linux and sysctl on macOS.
system.cpu.logical.countcount
Logical core count of the host. Opt-in metric, powers System Info → CPU Cores.

Memory

Memory metrics 3 metrics

system.memory.usagebytes
Memory in use per state (used, free, buffered, cached, slab_reclaimable, slab_unreclaimable), as reported by the kernel.
system.memory.utilizationpercent
Same as above, expressed as a fraction of installed memory. Convenient for alerts.
system.memory.limitbytes
Installed physical memory. Powers System Info → Total RAM.

Filesystem

Filesystem metrics 1 metric

system.filesystem.usagebytes
Used and free space per mount point, with device, mountpoint, mode, and type attributes. Rendered in the dashboard as a per-mount Filesystems table. The dashboard computes the utilization percentage from these two values, so there is no separate system.filesystem.utilization series to query.

Disk I/O

Block device metrics 1 metric

system.disk.iobytes
Bytes read and written per block device, with a direction attribute. Operation counts (system.disk.operations) are not ingested today.

Network

Interface counters 1 metric

system.network.iobytes
Bytes in and out per interface, per direction. The dashboard derives TX and RX byte rates from this in the Network table. Packet counts, per-interface errors, and dropped-packet counters are not ingested today.

Host metadata

Host metadata rides on every OTLP payload as resource attributes, so the dashboard stays accurate across reboots, kernel upgrades, and agent upgrades without any metadata-specific endpoint.

Hostname
As returned by gethostname.
Host ID
A stable machine identifier, unchanged across reboots, so a re-enrolled host is recognised as the same machine.
OS
Distribution and version, for example Ubuntu 22.04 or macOS 14.5.
Kernel
Kernel version string (uname -r).
Architecture
amd64 or arm64.
CPU model
Model name and vendor, shown in System Info → CPU Model.
Boot time
Derived from system uptime, shown in System Info → Boot Time.
Agent version
The installed agent version. When a newer release is available the dashboard shows an "update available" pill on the server row.

Uptime

System lifetime 1 metric

system.uptimeseconds
Seconds since the kernel booted. Used to render Boot Time in the System Info panel.

Collection cadence

Host metrics scrape
Every 30 seconds by the embedded OTel hostmetrics receiver.
Dashboard lag
Each scrape typically reaches Hyperping within a couple of seconds, so a graph update is visible within ~32s of the event on the host.
Persistent queue
Unsent metrics are queued to disk at /var/lib/hyperping/queue and retried automatically, so metrics survive ingest outages, reboots, and network blips.
Liveness
Derived from metric arrival: Online → Stale after ~30s without data → Offline after the per-server threshold (default 90s, floor 60s).

Retention

How far back the dashboard can scroll on each plan. High-resolution data ages out first; coarser rollups live longer, so a 6-month-old graph on Business still shows hourly points even after the minute-level data has been deleted.

Free
2 days of 1-minute history, 7 days at 5-minute, 30 days at 1-hour.
Essentials
7 days of 1-minute history, 30 days at 5-minute, 6 months at 1-hour.
Pro
14 days of 1-minute history, 60 days at 5-minute, 13 months at 1-hour.
Business
30 days of 1-minute history, 90 days at 5-minute, 13 months at 1-hour.

The 48-hour raw-scrape cache is uniform across plans. It is what the live server view reads for the current values on each panel, not what backs the historical charts. If you need longer retention than Business offers (audit, compliance), reach out; custom retention windows are available on Enterprise.

Next steps