Know why your internet feels slow.

RouteViewNet is a local-first network and memory health monitor for Linux. It watches your connection and your computer around the clock, scores their health from 0 to 100, and explains problems in plain English. No cloud. No account. No telemetry.

Free and open source (MIT) · Installs in one command · Runs entirely on your machine

0 health
localhost:4545

Overview

Health score ? 96 ✓ healthy last 24h
Download · wlp2s0 ? 1.8 MB/s total 458 MB
Upload · wlp2s0 ? 890 KB/s total 61.0 MB
Devices seen ? 3 visible from this machine
Open alerts ? 0 all clear
Gateway · 192.168.0.1 ? ✓ ok 2.4 ms
Internet ? ✓ ok 18.2 ms
DNS ? ✓ ok 6 ms
Memory ? 34% 10.7 GB of 31.2 GB
Load average (1m) ? 0.86 8 cores
Daemon memory ? 33.5 MB 22 goroutines
"the Wi-Fi is slow" "pages will not load" "is it the router?"

"The Wi-Fi is slow" has a dozen possible causes: your router, your provider, the DNS address book, a bad cable, or a computer that is simply out of memory. Guessing means restarting things at random. RouteViewNet measures each link in the chain continuously, so when something breaks you can see exactly which step failed and what to do about it.

What it does

One score that means something

A deterministic 0 to 100 health score computed from every check: router reachability, internet reachability, DNS speed, packet loss, memory, swap, and processor load. 90 or above is healthy; every lost point is explained.

The three lights: Gateway, Internet, DNS

The three-step path every web page takes, each checked every few seconds with response times. Which one fails tells you where the problem lives: your home network, your provider, or the address book.

Live bandwidth, per connection

Download and upload rates for every network interface, with automatic detection of the primary one on multi-homed machines. History from 15 minutes to 7 days, plus error and drop counters that expose bad cables, weak Wi-Fi, and overloaded links.

Data usage by app

See which programs moved the most data in any time window, with a view of every app that used 20 MB or more. Counted from the kernel's own connection counters and attributed to the owning process.

Internet health checks

Continuous latency and packet-loss probes to well-known reference addresses (configurable), plus DNS lookup timing for both IPv4 and IPv6 records, charted over time.

Devices on your network

Every device your computer talks to, with vendor lookup, optional hostnames, nicknames you assign, and a trusted flag. An unfamiliar device on your Wi-Fi raises a gentle alert.

Memory and load, demystified

System RAM (counted honestly: Linux cache does not count as used), swap pressure, 1/5/15-minute load against your core count, and the top memory consumers by name, so the culprit is one glance away.

Alerts that do not cry wolf

A problem must be seen twice in a row to open an alert, and alerts resolve themselves when the signal recovers. Debounced, deduplicated, and never requiring a dismiss button.

A Troubleshoot page that talks like a person

Rule-based diagnosis of the currently open alerts: a one-line likely cause, the evidence behind it, and ordered suggested actions. "Your gateway is fine, DNS is slow; check your resolver."

Tune it without restarting

Every knob lives in the dashboard: alert sensitivity (memory percentage, DNS latency, packet loss), check intervals and targets, per-collector toggles, data retention, and privacy switches. Changes apply the moment you save; the few that need a restart say so explicitly.

A real desktop app

RouteViewNet lives in your applications menu with its own window and icon, not just a browser tab. If the background monitor is ever stopped, the app offers to start it with your system's normal password prompt. The browser dashboard at localhost:4545 keeps working too.

The monitor watches itself

The daemon reports its own memory footprint in the dashboard, so you can verify the monitoring tool is not the thing slowing you down.

0telemetry calls
0SQLite file
0health score

Where exactly did it break?

Gateway 2.1 ms
Internet 18.4 ms
DNS 11.7 ms

All three steps healthy. Watching.

Who used the data?

Per-app usage in any time window, straight from the kernel's connection counters.

View all with 20 MB or more →

Up and running in a minute

  1. 1

    Install.

    One .deb package. The background monitor starts immediately and survives reboots.

  2. 2

    Open.

    Launch RouteViewNet from your applications menu (a native desktop window) or visit localhost:4545 in a browser.

  3. 3

    Understand.

    Glance at the score. If something is wrong, the Troubleshoot page tells you where and what to try.

$

Your data never leaves your machine.

  • [ ] No cloud, no account, no telemetry of any kind.
  • [ ] Everything lives in a single SQLite file on your disk; history older than 7 days is cleaned up automatically (configurable).
  • [ ] Process command lines are not stored by default, since they can contain secrets.
  • [ ] The dashboard answers only on the computer itself. Opening it to your LAN is an explicit setting with a persistent warning.
  • [ ] Defense in depth: host-header validation, WebSocket origin checks, strict CORS, a sandboxed systemd service with least-privilege capabilities.

Built for Linux users, honest by design

THE STACK

A single Go daemon, SQLite storage, a React dashboard embedded in the binary, systemd-managed. Hot-reloadable settings from the dashboard.

HONEST LIMITS

Shows devices this machine talks to, not a full LAN scan. Per-app usage counts direct (TCP) connections only. Load average only for CPU. No authentication in v1, so keep it local.

Questions, answered plainly

Does it slow my computer down?

No. It typically uses less memory than one browser tab, and it proves that on its own System page.

Do I need to keep the window open?

No, the monitor runs in the background; the window is just a viewer.

What Linux versions?

Debian and Ubuntu with systemd; Go 1.24 or newer to build from source.

Is it really free?

Yes, MIT licensed.

Can I see it from my phone?

Not out of the box; v1 has no authentication, so it stays local by default.