below: a time traveling resource monitor for Linux, built in Rust

The gap below fills: data you can only see after the fact

Most Linux monitoring answers the question "what is happening right now". That is fine until something happens at 03:00 and is gone by the time anyone opens a terminal. below is built around the opposite question: what was happening at a specific moment in the past. The README describes it as "an interactive tool to view and record historical system data", with three modes that map onto that idea. live shows the current system, record writes data to disk, and replay reads it back. The intended audience is the person debugging a production host after the incident, not the person building dashboards. The project name is a deliberate reaction to atop: the README says the below developers "rejected many of atop's design and style decisions", so this is a tool with an opinion about how system inspection should feel.

What below actually collects, and what it refuses to

The feature list in the README is short and specific. below reports hardware resource utilization, renders the cgroup hierarchy, shows cgroup and process information, and reads pressure stall information (PSI). PSI matters here because it is the kernel's own account of how long tasks waited on CPU, memory or IO, which is often the number you want when a host feels slow but nothing looks saturated. The repository layout backs up the scope: the Cargo workspace contains crates named cgroupfs, procfs, resctrlfs, ethtool, tc, gpu_stats and vmlinux, so collection is split by kernel interface rather than by metric type. The boundary is stated just as clearly. below does not support cgroup1. If your distribution or container runtime still mounts the v1 hierarchy, this tool is not a partial fit, it is the wrong tool.

Installing below from a distribution package

The fastest path on a supported distribution is the native package, because the packaging also ships a service unit for persistent recording. On Fedora, which has carried below since Fedora 34, the README gives this pair of commands. The first installs the binary; the second enables the systemd service that keeps recording in the background.

sudo dnf install below
sudo systemctl enable --now below

After the second command the service is enabled and started, so recording continues across reboots.

Alpine, Gentoo and Amazon Linux packaging

Alpine carries below in v3.17 and Edge, and uses OpenRC rather than systemd, so the service is started and registered separately. The README gives both commands, and the second makes the service persist across reboots.

sudo apk add below
sudo rc-service below start
sudo rc-update add below

Gentoo users install the sys-process/below package with emerge, and Amazon Linux carries below from AL2023.9 onward through dnf. If none of those match your distribution, the source route exists: the README instructs you to install the dependencies listed in docs/building.md first, then run cargo install below, and it notes a Dockerfile and pre-built images on Docker Hub with usage covered in docs/docker.md.

A first real use: live view, then replay

The quickstart in the README is three steps. Start with the live view, which needs root because it reads kernel interfaces.

sudo below live

If you installed through cargo rather than a package, the README's quickstart copies the binary into /bin and installs the bundled unit file before starting the daemon. The paths come from the repository, so the etc/below.service file must exist in your working copy.

sudo cp ~/.cargo/bin/below /bin/below
sudo cp etc/below.service /etc/systemd/system
sudo systemctl daemon-reload
sudo systemctl start below

Once the daemon has been running for a few minutes, the replay mode is what makes the design worthwhile. The -t flag takes a time expression, and the README's example asks for the state of the system three minutes ago.

below replay -t "3m ago"

For machine consumption, the dump subcommand emits script-friendly formats such as JSON, CSV and OpenMetrics, and the snapshot subcommand writes a replayable snapshot file of historical data. The README also points at contrib/grafana for basic Prometheus and Grafana integration through the dump interface.

Where below stops being the right tool

The cgroup1 exclusion is the hard limit, and it is the first thing to check on an older host. A second constraint is less obvious: below is a per-host inspector. The README describes recording and replaying system data, and the snapshot subcommand produces a file, but nothing in the documentation describes a central server that aggregates many machines. If your question spans a fleet, below gives you one host's history at a time. There is also an operational cost to record mode. A daemon writing to disk for months accumulates data that someone has to size and rotate, and the README does not document a retention policy. Treat the recording daemon as a service you must plan capacity for, not a fire-and-forget toggle.

below compared with atop, and with a metrics stack

The README's own comparison document, docs/comparison.md, positions below against alternative tools, and the name itself signals the reference point. The difference in approach is the mode split: atop is fundamentally a live process and system viewer with logging bolted on, while below treats recording and replay as first-class modes with a time expression as the entry point. The second comparison is against a Prometheus and Grafana deployment. Those systems are built for aggregation and long retention across many hosts, and below is not competing there; its dump interface exists so below data can reach that stack rather than replace it. Choose below when the unit of interest is one machine and the question is historical. Choose a metrics stack when the unit of interest is a fleet and the question is a trend.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-28, so it is under current development. Releases have arrived steadily: v0.9.0 on 2025-02-25, v0.10.0 on 2025-07-23 and v0.11.0 on 2025-09-24, which is a cadence of roughly two to five months rather than a nightly churn. That matters for upgrades, because a Rust workspace with this many crates will occasionally need a newer toolchain when you build from source; the Dockerfile pins fedora:42 as the builder image and installs clang, elfutils-libelf-devel, rustup and zig, which tells you the build has a real dependency surface. Building from source also requires the rustfmt component, since libbpf-cargo generates exitstat.skel.rs. The licence is Apache-2.0, declared in both Cargo.toml and the LICENSE file, which is permissive and typical for infrastructure tooling. That is a statement about the licence text, not legal advice; if you redistribute below or bundle it into a product, read the LICENSE file and your own policy.

Editorial conclusion

Adopt below if you run cgroup v2 systems and want historical resource data without wiring up a full metrics stack, especially on Fedora, Alpine, Gentoo or Amazon Linux where a package and a service file already exist. Skip it if your workloads still sit on cgroup v1, since the README states plainly that below does not support cgroup1. Before committing, verify two things on one representative host: that sudo below live renders your cgroup hierarchy, and that a recording daemon started from etc/below.service produces data that below replay -t "3m ago" can read back.

Frequently asked questions

Official sources

1. facebookincubator/below on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases