MySpeed

Automated internet speed monitoring, honestly reviewed. No marketing fluff — just what you get when you self-host it.

TL;DR

• What it is: Lightweight, MIT-licensed web app that runs scheduled internet speed tests and stores up to 30 days of results with charts and statistics [1].
• Who it’s for: Remote workers who need documented proof of connectivity problems, homelab users who want Grafana dashboards, small business owners who suspect ISP throttling but can never prove it.
• Cost: $0 software license. Runs comfortably on a $5–6/mo Hetzner VPS or a spare Raspberry Pi. No cloud tier, no subscription, no per-test pricing.
• Key strength: Three test backends (Ookla, LibreSpeed, Cloudflare), Prometheus/Grafana integration, and health notifications via email, Signal, WhatsApp, or Telegram — all in a single lightweight container [1].
• Key weakness: History is hard-capped at 30 days with no configurable retention. No authentication layer mentioned for multi-user access. At 2,799 GitHub stars it’s a healthy niche project, but smaller community than broader monitoring stacks.

---

What is MySpeed

MySpeed is a web application that answers one question: “Is my ISP actually delivering what I’m paying for, and do I have documented proof?” It runs automated speed tests on a schedule you configure, saves the results locally, and presents them as charts and statistics through a clean browser UI. That’s the whole thing — no cloud account, no agents, no subscription [1].

The project is maintained by gnmyt on GitHub, currently at 2,799 stars with an MIT license [1]. The core is simple on purpose: a cron-based scheduler fires a speed test, the result lands in a local database, and your dashboard updates. The 30-day history window means you’re not accumulating gigabytes of test data forever, which is a deliberate trade-off in favor of keeping this tool deployable on minimal hardware.

What distinguishes MySpeed from “just run Speedtest.net when you feel like it” is the automated history. ISP performance problems are almost never visible to a single manual test — throttling tends to be time-of-day dependent, congestion happens during peak hours, and slowdowns on Saturday night don’t show up when a technician checks on Tuesday morning. MySpeed gives you a timestamped record you can actually show someone.

For teams already running a monitoring stack, the Prometheus exporter and Grafana integration mean your internet speed data can live alongside CPU, memory, and disk metrics in the same dashboards [1].

---

Why people choose it

The category MySpeed sits in — automated speed test history — is surprisingly thin for self-hosted tools. There are a handful of alternatives (more on those below), but most of them either require more setup complexity or don’t support multiple test backends.

The ISP accountability angle. The most common reason people reach for a tool like this is after an argument with their ISP that went nowhere because they had no data. A single Speedtest screenshot proves nothing; a 30-day chart showing your connection drops to 12 Mbps every weekday between 7 PM and 10 PM is a different conversation. The health check notifications sharpen this further — if your connection drops below a threshold you set, you get a WhatsApp or Telegram message immediately rather than discovering the outage hours later [1].

Multiple test backends are more useful than they sound. Ookla’s Speedtest servers are the standard, but ISPs have been caught before routing Speedtest traffic through uncapped paths while throttling everything else. LibreSpeed runs against servers that aren’t operated by Ookla or your ISP, and Cloudflare’s speed test measures to a different point in the network. Running the same test against multiple backends gives you a more complete picture of where a bottleneck actually lives [1].

The Prometheus integration. For anyone already running a homelab monitoring stack, this is the feature that justifies the install over simpler alternatives. Speed test results as Prometheus metrics mean you can set alerts, build Grafana panels, and correlate internet performance against other events in your infrastructure [1].

Cron expressions for scheduling. Rather than a fixed interval picker, MySpeed uses standard cron syntax. This lets you do things like test more frequently during business hours and less frequently overnight — which is useful if you want dense data during the hours that matter without wasting bandwidth all night [1].

---

Features

Based on the README and project documentation [1]:

Core monitoring:

• Automated speed tests on a cron schedule of your choosing [1]
• Statistics on download speed, upload speed, and ping [1]
• Up to 30 days of stored test results [1]
• List view and statistics view for result browsing [1]

Test providers:

• Ookla Speedtest (the standard Speedtest.net backend) [1]
• LibreSpeed (open-source, self-hostable test servers) [1]
• Cloudflare speed test [1]
• Multiple servers can be added to a single MySpeed instance simultaneously [1]

Alerting and notifications:

• Health checks that fire when your connection drops below configured thresholds [1]
• Notification channels: email, Signal, WhatsApp, Telegram [1]

Observability integrations:

• Prometheus exporter [1]
• Grafana support [1]

Deployment:

• Linux and Windows installation guides [1][2]
• Docker is the standard path (not explicitly stated in README but standard for this type of project)

What’s not in the feature list:

• No multi-user authentication in the documented features
• No SLA report generation or data export
• No retention policy configuration (30 days is fixed)
• No alerting on improved performance (useful if you’re comparing before/after ISP plan changes)

---

Pricing: SaaS vs self-hosted math

MySpeed doesn’t have a cloud tier. It’s MIT-licensed software you run yourself — that’s the only option [1].

The cost comparison here is different from most self-hosted tools because there’s no direct paid SaaS equivalent to replace. Ookla’s Speedtest doesn’t offer automated historical tracking for personal or small-business users. What you’re replacing is either: nothing (manual one-off tests), or a generic network monitoring service that charges $20–80/mo for features that include speed testing as one component of many.

Self-hosted hosting costs:

• Raspberry Pi (existing hardware): ~$1–3/mo electricity
• Hetzner CAX11 VPS: ~$4.51/mo
• DigitalOcean Droplet (1GB): ~$6/mo
• Your own server alongside other services: $0 marginal cost

MySpeed’s footprint is small enough to share a VPS with other tools. If you’re already running Uptime Kuma or a reverse proxy on a small VPS, adding MySpeed adds negligible resource overhead.

The real savings calculation: if you’re currently paying a network monitoring SaaS $29–49/mo that includes speed test history as one feature among many, and MySpeed covers the speed monitoring piece for you specifically, the math is straightforward. Data on specific competing services’ pricing for this exact use case isn’t available for a precise comparison, but the general pattern — MIT software on a $5 VPS versus monthly SaaS — is consistent with every other tool in this category.

---

Deployment reality check

The README points to documentation at docs.myspeed.dev with separate guides for Linux and Windows [1][2]. No installation walkthrough is reproduced here, but the project’s simplicity suggests a standard path.

What you actually need:

• A Linux VPS or Raspberry Pi (the project’s hardware requirements are minimal — a Pi 3 or any low-end VPS handles this without breaking a sweat)
• Docker (recommended deployment method)
• A reverse proxy for HTTPS if you want to access it from outside your network (Caddy or nginx)
• An SMTP provider or Telegram/Signal bot setup if you want health check notifications

What the deployment probably looks like: Standard docker run or docker-compose command, single container, SQLite database included. The README mentions “add multiple servers” as a feature [1], which implies server configuration happens through the UI after installation rather than via config files.

What can go sideways:

• The Ookla backend requires the Ookla CLI to be available, which isn’t always included by default in minimal Docker images. Whether MySpeed’s container bundles it or requires a separate step isn’t documented in the README [1].
• LibreSpeed support implies you can point MySpeed at a LibreSpeed server you control — which is genuinely useful for isolated network testing, but means setting up LibreSpeed separately if you want that option.
• Notifications via Signal require the Signal CLI, which has its own non-trivial setup story. Email and Telegram are considerably simpler paths [1].
• If you want Prometheus + Grafana, you’re setting those up yourself. MySpeed provides the exporter endpoint; the monitoring stack is your responsibility [1].

Realistic time estimate: 30–60 minutes for a developer comfortable with Docker. 1–3 hours for someone following documentation for the first time. The Prometheus/Grafana integration path takes longer depending on what you already have running.

---

Pros and cons

Pros

• MIT license, no restrictions. Fork it, embed it, deploy it for clients — no commercial agreement required [1].
• Three test backends. Ookla, LibreSpeed, and Cloudflare in a single tool covers the main scenarios where backend choice matters for accurate results [1].
• Prometheus + Grafana integration. For homelab users who already have a monitoring stack, this makes speed data a first-class metric alongside everything else [1].
• Health check notifications with multiple channels. Email, Signal, WhatsApp, and Telegram support means you can plug into whichever alerting setup you’re already using [1].
• Cron-based scheduling. More flexible than a simple interval setting — lets you vary test frequency by time of day [1].
• Multiple servers per instance. You can test against several endpoints simultaneously, which is useful for diagnosing where in the network a problem lives [1].
• Low hardware requirements. Runs on a Raspberry Pi. Doesn’t need dedicated infrastructure.

Cons

• 30-day history cap is fixed. There’s no documented way to configure longer retention. If you want historical trend analysis beyond a month, you’d need to export data to a time-series database separately [1].
• No authentication layer documented. If you expose this to the internet without a reverse proxy auth layer (Authelia, basic auth), anyone who finds the URL can see your speed data and potentially your notification configurations. This isn’t unique to MySpeed, but it’s worth noting.
• Single-instance design. There’s no multi-user model, no team features, no role separation. Appropriate for personal or small-team use; not appropriate for anything requiring access controls.
• Smaller community than broader monitoring tools. 2,799 GitHub stars is respectable for a focused tool, but it’s well below the star counts of Uptime Kuma (~67K) or Netdata (~24K) [1]. Issue response times and plugin development reflect that.
• No data export or SLA reporting. If your goal is generating reports for ISP disputes or internal documentation, you’re building that yourself via Prometheus/Grafana or by querying the database directly.
• Signal notification setup complexity. Signal CLI is notoriously difficult to configure. The other channels are much simpler [1].

---

Who should use this / who shouldn’t

Use MySpeed if:

• You work remotely and your employer asks why you weren’t on the call — and you want documented evidence of exactly what your connection was doing.
• You’ve had the “our tests show everything is fine” conversation with your ISP and want 30 days of timestamped counter-evidence.
• You’re already running a homelab with Prometheus and Grafana, and you want internet speed as a metric in your existing dashboards.
• You suspect ISP throttling at specific times of day and want data that confirms or disproves it.
• You’re comparing performance before and after an ISP plan upgrade and want a clean benchmark.

Skip it (use Speedtest-tracker instead) if:

• You want a more actively developed alternative with more community plugins and a larger issue tracker.
• You need authentication built in rather than handled at the reverse proxy level.

Skip it (use Uptime Kuma instead) if:

• Speed testing is one of several things you want to monitor and you’d rather have one tool for HTTP checks, ping monitoring, and speed tests combined.

Skip it (use Telegraf + InfluxDB + Grafana instead) if:

• You’re already running InfluxDB and you want indefinite retention with configurable downsampling, not a 30-day hard cap.
• You need fine-grained control over what gets stored and queried.

Skip it entirely if:

• You’re on a business-grade connection with an SLA managed by your ISP’s own tooling — they have better visibility into their own infrastructure than any self-hosted speed tester.
• You need multi-location monitoring (MySpeed tests from where it’s installed, not distributed across locations).

---

Alternatives worth considering

• Speedtest-tracker — The closest direct alternative. Also self-hosted, Docker-based, uses Ookla by default, stores history. Larger community, built on Laravel. If you want more options for authentication and a more active project, start here.
• Uptime Kuma — Broader monitoring tool that includes basic speed test support alongside HTTP checks, ping monitoring, and status pages. Better choice if you want one dashboard for multiple types of monitoring. Doesn’t go as deep on speed test analytics.
• LibreSpeed — This is the speed test server, not a monitoring dashboard. You’d run LibreSpeed as your test backend and use MySpeed (or another tool) to query it and store results. Useful for keeping all network traffic inside your own infrastructure.
• Telegraf + InfluxDB + Grafana — The DIY approach. Telegraf has a Speedtest input plugin that pushes results to InfluxDB, which feeds Grafana. Much more setup, but indefinite retention, arbitrary data granularity, and fits into any existing InfluxDB workflow. Right choice if you already have this stack.
• Netdata — Full server and network monitoring with cloud sync. Includes internet speed monitoring as one metric among hundreds. Overkill if speed testing is all you need, but the right choice if you want comprehensive observability.
• Smokeping — Old-school latency and packet loss monitoring. Doesn’t measure throughput, but if your problem is jitter and latency rather than raw speed, it’s more relevant.

---

Bottom line

MySpeed does one thing — automated speed test history with notifications and Grafana integration — and it does it with no license strings attached and minimal hardware requirements. The 30-day history cap is a real limitation if you want long-term trend data, and the lack of built-in authentication means you need to handle access control at your reverse proxy layer. But for the core use case — documenting what your ISP is actually delivering over time, with alerts when it drops — it’s a clean, lightweight tool that gets out of your way.

The people who get the most out of this are remote workers dealing with unreliable connections and homelab operators who already have a monitoring stack and want internet speed as another metric. If that’s you, the install is worth the hour it takes. If you need longer history, look at Telegraf + InfluxDB. If you need more features and a bigger community, look at Speedtest-tracker.

If deployment is the blocker, upready.dev handles that — one-time setup, you own the infrastructure.

---

Sources

1. gnmyt/myspeed — GitHub Repository (MIT license, 2,799 stars). https://github.com/gnmyt/myspeed
2. MySpeed — Official Website and Documentation. https://myspeed.dev / https://docs.myspeed.dev