# systemstat: cross-platform system statistics in pure Rust

> systemstat is a Rust library that reports CPU load, load average, memory use, uptime, battery life, filesystem usage, disk I/O, network interfaces and traffic and CPU temperature, on Linux, macOS, Windows and the BSDs. Its defining choice is that it is written purely in Rust, with the platform-specific work done through per-target dependencies rather than by shelling out.

**valpackett/systemstat** — Rust library for getting system information | also on https://codeberg.org/valpackett/systemstat

- Repository: https://github.com/valpackett/systemstat
- Website: https://crates.io/crates/systemstat
- Stars: 671 · Forks: 80
- Language: Rust
- License: Unlicense
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/valpackett-systemstat

## A statistics crate with no foreign runtime

systemstat is a Rust library for getting system information and statistics, and the decision that shapes everything else about it is stated in one line of the README. Unlike sys-info-rs, this one is written purely in Rust. That matters for a specific set of projects. A crate that binds to the operating system's C libraries, or that shells out to tools written elsewhere, inherits the build complexity, the platform toolchain requirements and in some cases the licence obligations of those dependencies. A pure Rust crate compiles with a Rust toolchain and nothing else, and it is far easier to cross-compile. The cost is that the crate has to do the platform-specific reading itself, which is why the dependency list is organised around per-target crates rather than one large cross-platform binding. The audience is Rust developers building agents, desktop status tools, monitoring daemons or terminal applications, who want the numbers in Rust types rather than in the output of a subprocess.

## Adding the crate and reading the first numbers

The crate is published on crates.io under the name systemstat, and the package manifest in the repository shows the shape of it, including the edition, the licence and the version that the published crate currently carries:

```toml
[package]
name = "systemstat"
version = "0.2.7"
edition = "2018"
```

The README points at examples/info.rs for usage, and the API documentation is published on docs.rs, which is the faster route when you want to know which of the statistics are available for your target rather than reading the source. A first use therefore looks like this: add the crate to your own manifest, then call the accessors for the values you need, CPU load and memory usage being the usual starting pair for a status display. There is no service to start and no configuration file, because everything the library reports is read from the running system at the moment you ask for it.

## What the library actually reports

The feature list is a catalogue of what you can ask for. CPU load, and separately the load average. Memory usage. Uptime and boot time. Battery life. Filesystem mounts, along with disk usage for them. Disk I/O statistics. Network interfaces, and network traffic statistics. And CPU temperature. That last one is the entry most likely to surprise, because temperature is not a uniform concept across operating systems, but its presence tells you the crate is aimed at the dashboard and monitoring case rather than at a minimal resource probe. The distinction between interfaces and traffic statistics mirrors the same idea, since knowing that eth0 exists is a different question from knowing how many bytes have moved through it. The API is published on docs.rs, and the README points at the example file, examples/info.rs, as the usage reference, which is the natural place to see how a caller asks for each of these values.

## Platform work is isolated behind target gates

The manifest shows how the cross-platform promise is kept, and the mechanism is Cargo's target-specific dependency tables. The common dependencies are a time crate for timestamps, lazy_static, bytesize for human readable sizes and libc. On Linux, Android and Hurd the crate pulls in nom, a parser combinator library, which is a strong hint that the proc filesystem is parsed in Rust rather than by reading files with ad hoc string handling. Windows gets the winapi crate with a specific feature list covering fileapi, sysinfoapi, winbase, winerror, the Winsock definitions and pdh, which is the performance data helper used for the counters. Apple targets get mach2 for the Mach kernel interfaces, and illumos and Solaris get kstat-rs, which reads the kernel statistics framework. The design consequence is that a build for one platform compiles a fraction of the dependency tree, and a contributor adding a metric for one operating system touches one gated section.

## Serde support is an opt-in feature

The crate has a features table with a single entry, and it is worth reading because of how it is spelled. The feature is called serde, and it enables three things: the_serde, which is the serde crate itself renamed through a package alias, plus the serde support inside bytesize and the serde support inside the time crate. The renaming of the dependency is a deliberate trick so that the feature and the crate do not collide, a common pattern when a crate wants to turn on optional support for a dependency without claiming the dependency's name. For a monitoring application this is the difference between a struct you can serialise and one you cannot. The docs.rs build shows which targets are documented, with x86_64 entries for FreeBSD, OpenBSD, NetBSD, Linux gnu, Apple Darwin and Windows msvc chosen in the package metadata for the documentation build. The manifest also shows the package at version 0.2.7 using the 2018 edition, with the author listed as Val Packett and the licence given as Unlicense.

## Support is ordered by how complete it is

The README lists supported platforms, roughly ordered by completeness of support, and the list runs FreeBSD, Linux, OpenBSD, Windows, macOS, NetBSD and DragonFly BSD, followed by a note that more are coming soon. The ordering is the most useful line in that section, because it tells you where the crate has the longest history of attention and where you are more likely to hit a missing metric. The first entry being FreeBSD is also a signal about the project's origin and about where the maintainer has the most complete picture. The repository itself is a plain Rust crate, with a Cargo.toml, the src/ directory, an examples/ directory, and the CI configuration spread across .cirrus.yml for the BSDs, .woodpecker.yml and the GitHub workflows. The project is hosted on GitHub and mirrored on Codeberg, with the CI badge pointing at the Codeberg instance, so a fork on either host is a reasonable starting point.

## The alternative and how the approaches differ

The comparison the README makes is with sys-info-rs, and the difference is not a feature checklist but an implementation philosophy. sys-info-rs is not written purely in Rust, and that is the axis the author chose to highlight. For a project that already links system libraries for other reasons, the difference is small. For a project that wants a plain Rust build and no C library bindings, it is the whole decision. The other way to get the same numbers is to read the proc filesystem directly in your own code, or to shell out to tools like free or vmstat and parse their output, and both approaches cost you the same thing systemstat has already paid, which is platform-specific knowledge that has to be maintained for every operating system you claim to support, including the BSDs and the Unix variants where the interfaces differ. systemstat has paid that cost once, at the price of a fixed feature list and uneven depth between platforms.

## The Unlicense and a project that wants contributors

systemstat is released under the Unlicense, which the README describes as free and unencumbered software released into the public domain, with the text in the UNLICENSE file at the root. For a library, that is an unusually clean choice, since there is no attribution requirement, no copyleft obligation and no field-of-use restriction, and it makes the crate straightforward to vendor into a commercial or closed-source product. The same decision is applied to contributions, since the contributing section states that participating means agreeing to follow the Contributor Code of Conduct and to release contributions under the Unlicense. The project is explicit about accepting pull requests. On versioning, the crate on crates.io is 0.2.7 and the repository publishes no GitHub releases, so the published crate version and the manifest are the only reference points rather than a tag list. The default branch is trunk rather than main, and the last push to it was on 2026-09-19, which is your marker for how current the code is.

## Conclusion

systemstat suits a Rust application that needs to report on the machine it runs on, especially one that already avoids binding to system C libraries for build or licensing reasons, since the whole crate is pure Rust and the per-platform work sits behind a small set of gated dependencies. It is a poor fit for a program that needs deep platform introspection beyond the listed metrics, since the surface is a fixed list of statistics rather than a general system API, and the support ordering means the richest platform is FreeBSD rather than Linux. Before adopting it, check the docs.rs page for the platform you target and pin the version, since the published crate is 0.2.7 and the repository publishes no GitHub releases to track.

## FAQ

### What information can systemstat report?

CPU load, load average, memory usage, uptime and boot time, battery life, filesystem mounts and disk usage, disk I/O statistics, network interfaces, network traffic statistics, and CPU temperature. The README points at examples/info.rs as the usage reference and the API is published on docs.rs.

### Which platforms does systemstat support?

The README lists FreeBSD, Linux, OpenBSD, Windows, macOS, NetBSD and DragonFly BSD, roughly ordered by completeness of support, with more platforms planned. The crate handles platform differences through target-specific dependencies such as winapi on Windows, mach2 on Apple targets and kstat-rs on illumos and Solaris.

### Why choose systemstat over sys-info-rs?

The README points out that sys-info-rs is not written purely in Rust, while systemstat is. That matters when you want a plain Rust build with no system C library bindings, and it is the main difference the project highlights.

### Can the structs from systemstat be serialised?

Yes, through the optional serde feature, which the manifest defines as enabling the_serde, which is serde renamed through a package alias, together with the serde support in bytesize and in the time crate.

## Sources

- [Issues](https://github.com/valpackett/systemstat/issues)
- [License: Unlicense](https://github.com/valpackett/systemstat/blob/trunk/LICENSE)
- [Project website](https://crates.io/crates/systemstat)
- [README](https://github.com/valpackett/systemstat/blob/trunk/README.md)
- [valpackett/systemstat on GitHub](https://github.com/valpackett/systemstat)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/valpackett-systemstat