Catch your ISP throttling: build a Pi speed monitor

You know the feeling. The connection tanks a few times a week, streams buffer, calls drop — but every time you phone the ISP, "everything looks fine on our end." One frustrated Reddit user got tired of that answer and built a little bot to prove it, and the internet loved it. Here’s how to build your own line monitor, what it can (and can’t) prove, and how to turn the data into a complaint that actually lands.

First — be honest about what actually counts

Before you spend a weekend on this, get the framing right, or your evidence won’t hold up. Almost all South African fibre is sold as “best-effort, up to X Mbps” — not a guaranteed floor. So under-delivery isn’t one slow test; it’s a consistent pattern of falling well short. Four rules make your data trustworthy:

1. Test wired, not over Wi-Fi. Plug the monitor straight into the router/ONT by Ethernet. Wi-Fi congestion, distance and a weak router cause most “slow fibre” — and none of it is the ISP’s fault. A wired test is the only fair measure of the line.
2. Test to a local server. Pick a Johannesburg or Cape Town test server. Measuring to an overseas server understates your line and proves nothing about your ISP.
3. A speed test hits one server, not “the internet.” A slow result can be that server, peering or the far end — so trends over many tests matter, not any single number.
4. Log over days and weeks. Timestamped results showing you’re consistently getting, say, 40% of an advertised 100 Mbps line — wired, same local server — is a case. One bad afternoon isn’t.

The project that started it: netmon

The tool doing the rounds is netmon (github.com/Role1776/netmon) — a small, open-source (MIT) Python program. Every hour it runs a speed test and scans how many devices are on your network, logs both to a database, and every few hours posts a 24-hour chart to Telegram with a bit of (deliberately sarcastic) AI-written commentary.

The gimmicks — the AI snark, the Telegram bot — aren’t the point. The clever bit is the correlation: by logging speed and device count together with timestamps, it turns "it feels slow sometimes" into "the line collapses every evening at 8pm" — exactly the kind of pattern an ISP can’t wave away. Fair warning: it’s a new hobby project (a few dozen GitHub stars), and it uses the older speedtest-cli rather than Ookla’s official client, so treat it as a fun starting point, not a forensic instrument.

Build it: netmon on a Raspberry Pi

Any Raspberry Pi (or spare Linux box) works. Run 64-bit Raspberry Pi OS, and — this matters — plug it into your router by Ethernet. On the Pi’s terminal:

sudo apt update && sudo apt install -y nmap git python3-pip
pip install uv                      # netmon uses the uv package manager

# netmon scans your LAN with nmap, which needs passwordless sudo:
echo "$(whoami) ALL=(root) NOPASSWD: $(command -v nmap)" | sudo tee /etc/sudoers.d/netmon-nmap
sudo chmod 440 /etc/sudoers.d/netmon-nmap

git clone https://github.com/Role1776/netmon.git
cd netmon
uv sync                             # installs Python deps
cp .env.example .env
nano .env                           # add your Telegram bot token + chat ID,
                                    # and an LLM API key/endpoint (optional)
uv run main.py

By default it tests hourly (change the SLEEP_TIME value in seconds). To keep it running after a reboot, wrap it in a small systemd service so it starts on boot and restarts if it crashes — the repo’s README has a template. Results land in your Telegram chat; the raw data sits in a local SQLite file you can export later as evidence.

The easier, sturdier option: Speedtest Tracker

If you want something more polished and better for building a case, use Speedtest Tracker (alexjustesen/speedtest-tracker) instead. It’s actively maintained, uses Ookla’s official Speedtest CLI, has a proper web dashboard with history, and built-in threshold alerts to Telegram, Discord or email. It runs as a single Docker container on a Pi, a NAS (Synology/Unraid) or any always-on machine:

# generate an app key first:
echo "base64:$(openssl rand -base64 32)"

docker run -d --name speedtest-tracker --restart unless-stopped \
  -p 8080:80 \
  -e APP_KEY="base64:PASTE_THE_KEY_HERE" \
  -e DB_CONNECTION=sqlite \
  -e SPEEDTEST_SCHEDULE="0 * * * *" \
  -v /home/pi/speedtest-tracker:/config \
  lscr.io/linuxserver/speedtest-tracker:latest

Open http://your-pi-ip:8080 and you’ve got a dashboard. SPEEDTEST_SCHEDULE is a normal cron expression (0 * * * * = hourly). Set an alert threshold at, say, 60% of your advertised speed and it’ll ping you when the line dips — check the docs for the current options before you commit the config.

Even lighter alternatives

Just the official CLI + cron — the zero-frills route. Install Ookla’s Speedtest CLI and log a CSV every hour, then chart it in a spreadsheet:

0 * * * * /usr/bin/speedtest --format=csv --accept-license >> /home/pi/speedlog.csv

internet-monitoring (Docker + Prometheus + Grafana) gives you gorgeous latency/packet-loss dashboards, not just throughput — but the original repo is now archived, so use an active community fork rather than the original. And Cloudflare’s speed test is a good second data point (it measures loaded latency and jitter well), though Ookla to a local server is still the number an ISP will recognise in a dispute.

Turn the data into action (South Africa)

A month of wired, local-server logs showing a consistent shortfall is genuinely useful. Here’s how to use it in South Africa:

1. Complain to your ISP first — this step is mandatory. ICASA won’t investigate until you’ve logged it with the provider and given them time. Send your export (dates, times, wired results, local server, advertised vs measured) plus your router’s line-sync speed if you can see it. Get a reference number and allow them ~14 working days. Not sure who to call? Our fibre provider contact numbers list has the details.

2. Escalate to ICASA if it’s not resolved. Complaints must be in writing — lodge on the ICASA site or email the form to consumer@icasa.org.za, attaching your evidence and the ISP’s reference number. ICASA’s End-User and Subscriber Service Charter regulations set the minimum-service rules your complaint rests on.

The verdict

A Raspberry Pi speed logger is a genuinely satisfying weekend project, and it flips the script: instead of the ISP telling you everything’s fine, you’ve got timestamped proof either way. Sometimes it’ll show your line is actually solid and the problem is your Wi-Fi — which is worth knowing too. But if the data shows a real, persistent shortfall and your ISP still won’t fix it, you have the strongest argument there is: take your money elsewhere.