Tracium

Problem#

Most network monitoring tools are built for sysadmins: enterprise-grade, Windows-only, requiring self-hosted infrastructure, or narrowly focused on a single diagnostic (just speed, just Wi-Fi, just uptime). None of that fits someone who just wants to know why their home connection feels slow tonight, with enough history to actually make the case to an ISP.

Tracium is a lightweight, cross-platform desktop app that continuously monitors a home network — latency, jitter, packet loss, Wi-Fi signal, bufferbloat, DNS, and more — and keeps enough history to turn "the internet feels bad" into a report with real numbers behind it.

Motivation#

The gap wasn't just "no home network monitor exists" — it was that the ones that come close all made a trade-off that didn't fit: enterprise tools assume enterprise infrastructure, several options are Windows-only, others require self-hosting a server, and most cover only one aspect of network health rather than connectivity, speed, Wi-Fi, and reliability together. Tracium is built to continuously monitor a home network, collect historical metrics, detect real problems like latency spikes or bufferbloat, and generate reports that are actually useful during ISP troubleshooting — as a single lightweight desktop app, not a self-hosted stack.

Architecture#

Tracium is a Tauri 2 desktop app (React 19 + Vite frontend, not Electron) backed by a Rust Cargo workspace of four internal crates:

• tracium-probe — the actual network probes: ping/latency, DNS, Wi-Fi, bufferbloat, security/NAT checks, traceroute, bandwidth. Wraps librespeed-cli as an external process for speed tests rather than reimplementing one.
• tracium-monitor — orchestrates the probe sampler loop, computes Quality-of-Experience scores (gaming/video-call/streaming/browsing/VoIP), and detects outages.
• tracium-store — the SQLite persistence layer, shared between the GUI and a separate headless daemon (traciumd).
• tracium-cli — the traciumd binary: a full CLI (run, status, watch, report, dns, wifi, security, devices, route, bandwidth, speed, events, outages, export) that can run as an unprivileged systemd user service independent of the GUI.

The GUI and daemon share one SQLite database, with an explicit single-writer rule keeping concurrent access simple rather than building out a more complex synchronization layer.

Show source

Core Features#

• Continuous connectivity monitoring: RTT latency, jitter, packet loss, uptime, disconnect events, IPv4/IPv6 tracked separately.
• Scheduled speed tests (download/upload, ping/jitter under load) via librespeed-cli, with full history and peak-vs-off-peak comparison.
• Wi-Fi diagnostics: RSSI, signal quality, link speed, channel/band, noise, retransmission rate.
• Bufferbloat detection with a real A–F grade, computed from latency increase under concurrent load.
• DNS diagnostics (per-resolver comparison, cache hit rate), traceroute with per-hop latency and route-change detection, and basic security checks (open ports, NAT type, UPnP, VPN detection).
• Quality-of-Experience scoring per use case (gaming, video calls, streaming, browsing, VoIP).
• A full CLI (traciumd) that runs headless as an unprivileged systemd user service, independent of the GUI, with JSON output and time-windowed queries on every read subcommand.
• PDF and CSV report/export generation.

Per-device and per-application bandwidth breakdown is explicitly not implemented — it's documented in the project's own build-order notes as deferred by deliberate decision, not an oversight (see Engineering Challenges).

Technical Decisions#

Speed testing wraps librespeed-cli as an external subprocess rather than statically linking against it or reimplementing speed testing from scratch. librespeed-cli already solved that problem well, and shelling out to it as a separate process — rather than linking against its LGPL-3.0 code — let Tracium stay MIT-licensed and easy to distribute while still benefiting from a mature, maintained speed-test implementation.

Tauri (not Electron) was chosen as the desktop framework specifically for a lightweight utility like this: a smaller runtime footprint than Electron, while still getting native integration and a modern web-based UI layer (React + Vite).

Engineering Challenges#

The most significant architectural decision in the project so far wasn't a specific implementation problem — it was deciding what Tracium wasn't going to do. Per-device and per-application bandwidth breakdown sounds simple, but doing it correctly requires elevated privileges: kernel-level hooks like eBPF, platform-specific drivers like Npcap, or depending on GPL-licensed tooling. That conflicted directly with the project's goals of staying lightweight, cross-platform, and simple to install. Rather than compromising those goals for one feature, that work was deliberately scoped out and documented as future work — a decision that shaped the overall architecture more than any single implementation challenge.

Bufferbloat detection runs the speed test as a concurrent load generator while sampling round-trip time throughout — but that measurement itself wasn't the hardest part of the project. Most of the real complexity came from coordinating the probe, monitor, and storage subsystems reliably across platforms while keeping the GUI responsive, rather than from any single measurement technique.

Screenshots#

Lessons Learned#

Building Tracium reinforced that not every application needs its own embedded AI assistant. Most users already have access to a capable general-purpose LLM. Generating a structured report and letting people bring their own model — rather than building and maintaining a bespoke analysis engine — is simpler, easier to maintain, and doesn't lock anyone into a specific AI provider. Native "AI insights" can always be layered on top of the existing reporting pipeline later if there's real demand for it; there was no reason to build that first.

Tauri also held up well in practice: for a desktop utility like this, it struck a good balance of performance, memory footprint, native integration, and developer experience, and validated that a modern desktop app doesn't need Electron's much larger runtime to feel native and responsive.

Current Status#

Actively developed: 72 commits since the repository was created on 2026-07-05, with one draft v0.1.0 GitHub release (not yet publicly published) providing Linux packages (.rpm, .deb, AppImage) and a standalone traciumd binary. AUR and Snap packaging are ready to publish; a Flathub build needs an extra vendoring step. Windows support is present but explicitly marked experimental — Linux is the more complete platform today.

Tech Stack#

Rust (Cargo workspace), Tauri 2, React 19, TypeScript, Vite, SQLite via sqlx, Tokio. Notable crates: hickory-resolver (DNS), sysinfo/netdev (interfaces), csnmp (router SNMP), stunclient/igd-next (NAT/UPnP), clap (CLI), printpdf (report generation). Speed testing wraps the external librespeed-cli binary rather than a bundled crate.

Related Content#

Browse the rest of my personal projects.