Speedtest Tracker

Speedtest Tracker is a self-hosted app that runs the Ookla Speedtest CLI on a schedule and stores every result, download, upload, ping, and packet loss, in a dashboard you control. Instead of one speed test screenshot taken on a good day, you get months of history that shows what your connection actually does at 3am, during a storm, or right after your ISP swears they “fixed” something.

What Speedtest Tracker actually does

The core loop is simple: a cron schedule you define fires off a real Ookla speed test at whatever interval you pick, every 30 minutes, every 6 hours, whatever, and the result lands in a database with download and upload throughput, ping, jitter, and packet loss attached. Over a few weeks that turns into a chart, and charts are much harder for an ISP to argue with than “it feels slow.”

Notifications go out through Apprise, which means one config unlocks Discord, Telegram, email, Slack, ntfy, and a long list of other services, and you can set thresholds so it only pings you when a result drops below a number you define, not on every single test. You can also point tests at specific Ookla servers instead of whatever’s nearest, useful if you want to consistently benchmark against the same server your ISP’s peering actually uses, and old results can be auto-pruned after a set number of days so the database doesn’t grow forever.

Installing Speedtest Tracker with Docker

The image is maintained by LinuxServer.io rather than the app’s original author, a common pattern for self-hosted tools once they get popular enough. It ships with SQLite by default, so there’s no separate database container to stand up for a first run, though Postgres and MySQL are supported if you’d rather point it at an existing instance.

services:
  speedtest-tracker:
    image: lscr.io/linuxserver/speedtest-tracker:latest
    container_name: speedtest-tracker
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - APP_KEY=
      - APP_URL=http://192.168.1.50:8765
      - DB_CONNECTION=sqlite
      - SPEEDTEST_SCHEDULE=0 */6 * * *
      - SPEEDTEST_SERVERS=
      - DISPLAY_TIMEZONE=Etc/UTC
      - PRUNE_RESULTS_OLDER_THAN=90
    volumes:
      - ./data:/config
    ports:
      - 8765:80
    restart: unless-stopped

1. Generate an APP_KEY before first boot; the container will warn on startup if it’s missing. The official installation docs walk through generating one with the container’s own artisan command.
2. Save the compose file above, adjusting APP_URL to match how you’ll actually reach the container, and run docker compose up -d.
3. Open the web UI and log in with the default admin@example.com / password, then change both immediately.
4. Set SPEEDTEST_SCHEDULE in standard cron syntax. 0 */6 * * * runs a test every six hours; running it every few minutes is overkill for most home connections and just burns bandwidth on tests instead of whatever you’re actually trying to do online.
5. Under Settings, wire up an Apprise notification URL if you want alerts when a test drops below your normal baseline.

docker compose up -d

Homelab use cases

The most common reason people install this is to build a paper trail against their ISP. Support reps love to say “everything looks fine on our end” when your connection has been crawling for a week, and a chart with three months of timestamped, geolocated Ookla results is a much stronger argument than “it feels slow,” especially when you’re paying for a specific contracted speed and consistently getting 60% of it during evening hours.

The second use case is catching silent degradation. Connections rarely die outright, they just get a little worse after a firmware update, a bad splice in the neighborhood, or your ISP quietly oversubscribing a node near you. Without a running history, small drops go unnoticed until they compound into “why does everything feel bad lately.” With Speedtest Tracker logging every few hours, you can correlate a dip against a specific date and go back through your own change log, router update, new device on the network, ISP maintenance window, to actually find the cause instead of guessing.

Speedtest Tracker vs a DIY cron script vs Uptime Kuma

You don’t strictly need Speedtest Tracker to log speed test results, a cron job calling the Ookla CLI and dumping output into a CSV does the same core job. The difference is everything Speedtest Tracker builds around that raw data: a dashboard, charts, notification thresholds, and pruning, without you writing and maintaining that tooling yourself.

	Speedtest Tracker	Cron + Ookla CLI script (DIY)	Uptime Kuma
Setup effort	One container, a docker-compose file, and an APP_KEY	Write and maintain your own scripts, parsing, and storage	One container, no config needed for a first monitor
What it measures	Download, upload, ping, jitter, packet loss via real Ookla tests	Same raw data, if you build the parsing yourself	Up/down state and response latency, not throughput
Dashboard & charts	Built in, filterable history out of the box	None, you’d build this yourself or dump to Grafana	Built in, but for uptime, not speed
Notifications	Apprise, 70+ services, threshold-based	Whatever you script	90+ services built in
Best for	Proving ISP performance over time	Full control if the built-in dashboard doesn’t fit your needs	Knowing whether a service is reachable at all

Worth being clear about: Uptime Kuma and Speedtest Tracker solve different problems and pair well together rather than compete. Uptime Kuma tells you a service or host is reachable and how fast it responded to a ping or HTTP request. It has no idea what your actual download throughput is, and it isn’t meant to. If you want both “is my internet up” and “is my internet actually fast,” you end up running both.

Speedtest Tracker: pros and cons

• Uses Ookla’s actual test infrastructure, the same servers and methodology behind speedtest.net, so results are directly comparable to what you’d see running a manual test
• Single container with SQLite by default, nothing extra to provision for a first deploy
• Threshold-based Apprise notifications mean you find out about a bad connection without babysitting a dashboard
• Historical charts turn a vague complaint into a concrete, timestamped argument for an ISP support call

• Every scheduled test consumes real bandwidth; running it too frequently competes with whatever else is using the connection
• Relies on Ookla’s third-party CLI and server network rather than a fully self-contained measurement, so it’s not 100% independent of an outside service
• Requires generating and setting an APP_KEY before it’ll start cleanly, a small extra step compared to zero-config tools
• Measures throughput and latency only, no packet-level diagnostics or traceroute-style troubleshooting built in

FAQ

Is Speedtest Tracker free?

Yes, the app is MIT licensed with full source on GitHub and no paid tier. The only cost consideration is the underlying Ookla CLI, which is free to use under its own EULA for personal, non-commercial use, the kind of scheduled home-connection testing most people run this for.

Does it use my Ookla speedtest.net account?

No account is required. It calls the Ookla CLI directly, which runs anonymously against Ookla’s public server network, the same infrastructure speedtest.net uses in a browser, just without a login attached.

Can I choose which server it tests against?

Yes, via the SPEEDTEST_SERVERS environment variable, a comma-separated list of Ookla server IDs. Left blank, it auto-selects the nearest server, which can vary slightly between runs; pinning a specific server ID gives you more consistent, apples-to-apples results over time.

How is this different from just running speedtest-cli manually?

A manual test only tells you about the moment you ran it. Speedtest Tracker automates that same underlying test on a schedule and keeps the history, so you can see patterns over days or weeks instead of a single data point that might just have caught a good or bad moment.

Should I expose the dashboard to the internet?

Not directly. Like most self-hosted dashboards, it’s meant to be reached over your LAN or through something like a reverse proxy with authentication or a VPN such as Tailscale if you want remote access, rather than port-forwarded straight to the open internet.

Speedtest Tracker earns its spot in a homelab the same way Uptime Kuma does: it’s a small, single-purpose container that answers one specific question well, in this case “is my ISP actually delivering what I’m paying for.” Pair it with Uptime Kuma for the uptime side of things and Netdata if you also want visibility into what your own hardware is doing while those tests run. Our homelab setup guide for beginners covers the Docker basics all three depend on, and the Monitoring category rounds out the rest of the tooling here.