Zero to 700 Stars: Building a Rust TUI Network Analyzer
The setup was always the same. You SSH into a server that's behaving strangely, and you immediately hit a wall. top shows CPU is fine. iftop needs root. nethogs shows process names you don't recognize and packet counts in units that don't map to your mental model. There's no clean way to answer the question you actually have: is this server's network healthy right now?
netwatch started as a personal fix for that. I wanted one binary, no root, no configuration, that could tell me: interface bandwidth, gateway latency, packet loss, DNS latency, connection count. Everything relevant to "can this server reach the world?" — readable in a terminal, refreshing live.
Building with ratatui
The Rust TUI ecosystem in 2024 was ratatui plus figuring most things out yourself. ratatui is excellent — a composable widget model, a well-designed event loop, enough flexibility to make something that actually looks good. What it doesn't give you is opinions about architecture.
The main challenge with a network monitoring TUI is the polling model. You have multiple metric sources — /proc/net/dev for interface stats, ICMP pings for latency, /proc/net/tcp for connections — each with different refresh intervals. Getting these to compose cleanly without threads blocking each other took a few iterations.
The pattern I landed on: one background thread per metric source, each writing to a shared RwLock<MetricCache> at its own cadence. The render loop reads from the cache at 1 Hz, so the UI stays smooth even if a ping times out and stalls for 500 ms. The cache acts as a decoupling layer between "how fast can we collect" and "how fast should we draw."
No root, by design
A non-negotiable early decision: no root required. Everything netwatch reads is in /proc and /sys, which are world-readable on every modern Linux distribution. The one exception is ICMP socket creation — modern Linux supports unprivileged ICMP_ECHO sockets since kernel 3.x, so we use those.
This matters more than it sounds. If a tool requires sudo, it goes in the "too much friction" pile for most developers. A single binary you can scp to a server and run immediately — without privilege escalation — is a fundamentally different experience.
700 stars without a marketing budget
It started with a post in r/rust. The tool was useful, the post was honest about what it did and didn't do, and it got enough upvotes to reach people who actually needed it. Growth since then has been the same pattern: word of mouth from developers who found it useful and told others. We've posted in other communities and forums over time, but that first r/rust thread is where it began.
What I didn't expect: how many people use it as a live debugging tool during production incidents. "I had netwatch running in a tmux pane and that's how I caught the packet loss spike" came up more than once. That's exactly the use case the tool was built for. It's satisfying when the problem statement turns out to be exactly right.
What's next
The CLI tool is stable, actively maintained, and open source on GitHub. The logical extension is a hosted layer — persistent metric history, alerting, and a fleet dashboard for servers you can't babysit with a terminal. That's what NetWatch Cloud is: the same lightweight Rust agent, plus a backend that stores your data and pages you when something breaks. It's coming. In the meantime, the CLI tool works today and costs nothing.