SmokePing

Network latency visualization, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: Free, open-source (GPL-2.0) network latency monitoring tool that measures, stores, and visualizes ping times, jitter, and packet loss over time using RRDtool graphs [2].
• Who it’s for: Home lab operators, sysadmins, and anyone running self-hosted infrastructure who needs to prove to their ISP that the problem is on their end — not yours [1].
• Cost savings: There is no SaaS version of SmokePing. It’s purely self-hosted, purely free. The cost is a small Linux VM or Docker container — as low as $5/mo on any VPS [1].
• Key strength: Nothing else in the open-source space matches SmokePing for long-term latency trend visualization. It doesn’t just tell you a host is down — it shows you the pattern of degradation over days and weeks [1][2].
• Key weakness: The project’s website looks like it was designed in 2007 because it was — last significant content update was 2007. The UI is showing its age, the install process is Perl-era pain, and Docker is the only sane path to running it in 2026 [1][2].

---

What is SmokePing

SmokePing is a latency logging, graphing, and alerting system. You point it at hosts — your router, your ISP’s gateway, Google’s DNS, a remote server — and it continuously pings them, records the round-trip times, and draws graphs that show you not just whether a host is reachable, but how stable the connection is over time [2].

The tool was created by Tobias Oetiker, who is also the author of MRTG (Multi Router Traffic Grapher) — one of the original network monitoring tools. SmokePing uses his RRDtool library under the hood to maintain a round-robin database of latency samples and generate the characteristic “smoke” graphs that give the tool its name. The smoke in the graph represents the spread of latency measurements: a tight, thin line means consistent response times; a wide, billowing cloud means your connection is jittery and unreliable [1][2].

The project sits at 1,842 GitHub stars and is licensed under GPL-2.0. It’s written entirely in Perl [2]. The GitHub description calls it simply “The Active Monitoring System,” and the homepage calls it “a deluxe latency measurement tool.” For once, the marketing is accurate without being inflated.

What sets SmokePing apart from a basic ping utility is the combination of three things: it sends multiple pings per interval (not just one), stores the results in a time-series database that persists indefinitely, and renders those results in a way that makes latency patterns immediately legible to a human. When your VMs started lagging at 11 PM every night last week, SmokePing is what tells you whether that was a network issue, an ISP issue, or a coincidence [1].

---

Why people choose it

The core use case that comes up repeatedly in reviews is ISP accountability [1]. Without historical latency data, you have no leverage when calling your ISP about a connectivity problem. “It felt slow” is not a support ticket. A graph showing 40% packet loss every evening between 8 PM and 11 PM, with timestamps, is a different conversation. SmokePing exists to produce exactly that evidence [1].

Beyond ISP disputes, the Virtualization Howto review [1] calls out several other home lab scenarios where SmokePing earns its keep:

• Packet loss from a flaky cable or switch port that only manifests intermittently
• Latency spikes during VM migrations or backup jobs that explain why the UI felt sluggish
• Poor Wi-Fi performance between access points showing up as jitter rather than outright loss
• Verifying that a network change actually improved things, not just feeling like it did

The master/slave deployment model is a frequently mentioned feature. One SmokePing master can coordinate multiple slave nodes in different physical locations, all reporting back to a central graph store [1][2]. For home labbers with hardware in multiple locations — or a company with branch offices — this means you can ping a single target from multiple sources and see whether a latency problem is local or global. The data stays centralized; the measurements are distributed.

LinuxLinks [2] highlights the probe extensibility as another reason people choose SmokePing over simpler tools: it’s not just ICMP ping. The probe system supports web requests, DNS queries, LDAP, SSH, and custom protocols. If you want to measure not just “is Google reachable” but “how fast is my DNS resolver responding,” SmokePing can do that with a different probe.

---

Features

Based on the official documentation and reviews:

Core measurement engine:

• Sends multiple ICMP echo requests per target per interval and records the full distribution of response times, not just the average [1][2]
• Tracks minimum, maximum, and median round-trip times — the spread between these is what produces the “smoke” visualization [1]
• Detects and records packet loss (unanswered pings) separately from high latency [2]
• Standard deviation calculation for quantifying jitter [website]
• Configurable measurement intervals

Probe system:

• Pluggable probe architecture — ICMP ping is the default, but probes exist for DNS, HTTP/HTTPS, FTP, LDAP, SMTP, SSH, and more [2][website]
• Custom probe development possible via the plugin system
• Each target can use a different probe type

Alerting:

• Advanced alarm system that triggers on configurable “latency patterns” — not just simple threshold breaches [2][website]
• Pluggable matchers for alarm conditions
• Can alert on combinations of conditions over time (e.g., “sustained high latency for 5 minutes”)

Visualization:

• RRDtool-backed long-term storage with no data expiry (round-robin means oldest data is averaged down, not deleted) [1]
• Ajax-based interactive graph zooming — click to mark a time range in the navigator graph [website]
• Multi-target graphs to show multiple hosts in a single view [website]
• Chart mode to surface the most problematic targets first [2][website]

Deployment:

• Master/slave model for multi-location monitoring from a single pane [1][2][website]
• Dynamic IP support for cable/DSL connections [README]
• Web interface via CGI
• Docker is the recommended modern deployment path [1]

What it does not do:

• No service uptime checks (HTTP 200 responses, certificate expiry, etc.) — that’s Uptime Kuma’s job
• No infrastructure metrics (CPU, memory, disk) — that’s Prometheus/Grafana
• No alerting to modern platforms (PagerDuty, Slack, Discord) out of the box — the alarm system is old-school email and scripts
• No modern web UI — it’s CGI-era HTML rendered by Perl

---

Pricing: SaaS vs self-hosted math

SmokePing has no SaaS version, no cloud offering, no commercial tier, and no pricing page. It is free software under GPL-2.0, full stop [2].

What it actually costs to run:

• Software license: $0
• VPS to run it on: $4–8/month on Hetzner, Contabo, or DigitalOcean — a 1GB RAM instance is sufficient for a typical home lab deployment
• Docker (preferred) or bare-metal Perl install
• A domain and reverse proxy if you want HTTPS on the web interface

What the commercial alternatives cost:

PingPlotter (the closest SaaS equivalent for latency monitoring) runs $14.95/month per user for the Standard plan, $39.95/month for Professional. Paessler PRTG charges per sensor, with the free tier capped at 100 sensors. Datadog Network Performance Monitoring starts around $5/host/month and climbs fast.

For home lab use, the math is simple: SmokePing plus a $5/mo VPS costs $60/year and monitors unlimited targets indefinitely. PingPlotter Standard costs $179/year per user. PRTG’s free tier is free but capped. SmokePing has no caps.

For business use, the calculus is different — a modern SaaS latency monitoring tool comes with support, a maintained UI, and integrations with your alerting stack. SmokePing comes with a Perl codebase and a 2007-era web interface. The question is whether the cost savings justify the operational overhead.

---

Deployment reality check

The honest answer: if you’re running Docker, SmokePing is a one-afternoon project. If you’re not, it’s a Perl dependency nightmare that has aged poorly [1].

The community has mostly solved this by containerizing SmokePing. The Virtualization Howto review [1] runs it in Docker and reports it as lightweight and straightforward. The linuxserver/smokeping Docker image is the standard approach — it handles the Perl dependencies and CGI setup inside the container and exposes the web UI on a port you map.

What you actually need:

• Docker (strongly recommended — bare Perl install is painful)
• A Linux host with 512MB–1GB RAM minimum
• A text editor and patience for the INI-style config file
• A reverse proxy (nginx, Caddy) if you want HTTPS
• An SMTP server or relay if you want email alerts

What the config looks like:

SmokePing configuration is a flat INI-style file divided into sections: General, Alerts, Database, Presentation, Probes, Slaves, and Targets. Targets are defined hierarchically — you can group them into sections (e.g., +ISP, +Internal, +External) and SmokePing renders the hierarchy in the web UI. This is powerful but verbose. Adding 20 targets requires 20 config blocks [website][README].

What can go sideways:

• The CGI web interface requires a web server (Apache or nginx) with CGI enabled, which is increasingly unfamiliar territory for people who’ve only used modern web apps. Docker images handle this internally, which is why they’re recommended.
• The graph rendering requires fonts and RRDtool installed correctly inside the container — the linuxserver/smokeping image handles this, but rolling your own image is an exercise in yak-shaving.
• The config file syntax has gotchas. Indentation with spaces vs. tabs matters. A misconfigured target silently produces no graph rather than an error message.
• No REST API, no webhook output, no Slack integration built in. Alerts go to email. If you want PagerDuty or Discord notifications, you’re writing a script that parses the alert emails.
• The web UI is not mobile-friendly. It’s CGI-era HTML. It works in a browser; it’s not pleasant on a phone.

Realistic time estimate: 1–2 hours to a working Docker deployment with basic targets configured. Add another hour if you want HTTPS and a clean domain. Add an afternoon if you’re doing bare-metal Perl installation (and reconsider your life choices).

---

Pros and cons

Pros

• Best-in-class latency visualization. The smoke graph format is genuinely the most information-dense way to display latency distribution over time. Nothing in the free/open-source space matches it for this specific use case [1][2].
• Long-term historical data. RRDtool stores indefinitely (with resolution tradeoffs over time). You can pull up latency graphs from six months ago. This is what you need when arguing with your ISP [1].
• Completely free, no limits. No per-target caps, no seat licenses, no feature tiers. Unlimited targets, unlimited retention [2].
• Master/slave for multi-location. The ability to measure a single target from multiple vantage points is genuinely useful and not common in free tools [1][website].
• Pluggable probe system. Measure more than just ping: DNS, HTTP, SSH, custom protocols [2][website].
• Lightweight. Runs on a 512MB RAM instance. Doesn’t need a database server — RRDtool files are flat files on disk [1].
• Proven over 20+ years. It’s not going anywhere, the data format is stable, and the community knows how to run it.

Cons

• Antique UI. The web interface is CGI Perl from the early 2000s. It works, but it’s not pretty, it’s not responsive, and it’s not configurable without touching code [website].
• Config file-only setup. No web-based configuration. Every target, probe, and alert requires editing a text file and reloading the daemon. For 5 targets this is fine. For 50 it’s tedious.
• Perl dependency pain. Bare-metal installation requires resolving Perl module dependencies that don’t always install cleanly on modern distributions. Docker is essentially mandatory for sanity [1].
• No modern alerting integrations. Email only, out of the box. Slack, Discord, PagerDuty require custom scripts [2].
• No uptime monitoring. SmokePing measures latency and packet loss — it doesn’t check whether your HTTP service returned a 200, your TLS certificate is expiring, or your API responded correctly. You need a separate tool (Uptime Kuma, Gatus) for that.
• Minimal community activity. The GitHub repo has 1,842 stars and was described as “The Active Monitoring System” — but the website’s last content update was 2007. Development continues but slowly. Feature requests don’t move fast.
• No mobile-friendly interface. If you want to check latency graphs from your phone, prepare to squint.

---

Who should use this / who shouldn’t

Use SmokePing if:

• You run a home lab and want to know whether your ISP is the problem or your switch is the problem — and you want a year of historical data to prove it.
• You’re a sysadmin who needs long-term network latency trending for SLA reporting or incident post-mortems.
• You have multiple locations and want to measure network quality between them from multiple vantage points using the master/slave model.
• You want something free, self-contained, and reliable that you can forget about once it’s running.
• You’re comfortable with Docker and config file editing.

Skip SmokePing (use Uptime Kuma instead) if:

• You primarily want to know whether services are up or down rather than how latent or jittery they are. Uptime Kuma is more beginner-friendly, has a modern UI, and handles service uptime checks across HTTP, TCP, DNS, and more.

Skip SmokePing (use Prometheus + Grafana instead) if:

• You want a full observability stack — CPU, memory, disk, network, custom metrics — with flexible dashboarding and Alertmanager integration. The setup overhead is much higher, but the scope is incomparable.

Skip SmokePing (use Gatus instead) if:

• You want health checks that actually verify your service’s behavior (e.g., “does this API return the right JSON”) rather than just measuring round-trip ping time.

Skip SmokePing (use PingPlotter instead) if:

• You’re on Windows, not comfortable with Docker and Linux, and willing to pay $15/month for a polished desktop application that does the same thing with a modern UI.

---

Alternatives worth considering

• Uptime Kuma — the modern, beginner-friendly uptime monitor. Great web UI, Docker-native, Discord/Slack alerts built in. Focuses on service uptime rather than latency trending. Not a replacement for SmokePing; a complement to it.
• Prometheus + Grafana with ping exporter — you can recreate most of SmokePing’s functionality in a Prometheus/Grafana stack using a ping exporter. More setup, much more flexibility, and you get the rest of the observability stack too.
• Gatus — service health monitoring with configurable endpoint checks. Modern, YAML-configured, supports complex conditions. Doesn’t do long-term latency trending the way SmokePing does.
• Zabbix — enterprise-grade monitoring that includes ICMP monitoring along with everything else. Significant setup overhead, but covers infrastructure monitoring, alerting, and reporting in one package [4].
• PingPlotter — the closest commercial equivalent. Clean UI, available for Windows/Mac, paid tiers start around $15/month. Good if you want SmokePing’s functionality without the Linux/Docker setup.
• mtr — a command-line tool that combines traceroute and ping. No persistence, no graphs, but great for real-time diagnosis of where in the network path latency is occurring [3].
• Nagios — older monitoring platform with ICMP check plugins. Much broader scope than SmokePing, much heavier setup, less elegant latency visualization [3].

For the specific job of long-term network latency visualization, there is no free open-source tool that beats SmokePing. The alternatives solve adjacent problems.

---

Bottom line

SmokePing is a 20-year-old tool that solves a specific problem better than anything else available for free: it shows you what your network latency looked like over the past week, month, or year, and it makes packet loss visible in a way that’s legible to a human who needs to explain it to an ISP support agent. The UI is dated, the install is Perl-era, and Docker is the only realistic path for anyone who values their time. But once it’s running, it runs quietly and indefinitely on the cheapest VPS you can find, accumulating data that will matter exactly when you most need it — during a network incident when you need proof, not just a feeling [1]. If you’re running any self-hosted infrastructure and you don’t have long-term latency visibility, SmokePing is the gap you’re missing.

---

Sources

1. Brandon Lee, Virtualization Howto — “Smokeping is the Simple Way to Monitor Pings in Your Home Lab” (November 8, 2025). https://www.virtualizationhowto.com/2025/11/smokeping-is-the-simple-way-to-monitor-pings-in-your-home-lab/
2. LinuxLinks — “SmokePing - latency measurement tool”. https://www.linuxlinks.com/smokeping-latency-measurement-tool/
3. AlternativeTo — “Great PingPlotter Alternatives: Top Network Monitors in 2025”. https://alternativeto.net/software/pingplotter/
4. Ayush Pande, XDA Developers — “5 of the best tools for monitoring your home lab” (January 31, 2025). https://www.xda-developers.com/best-tools-for-monitoring-your-home-lab/

Primary sources:

• GitHub repository: https://github.com/oetiker/smokeping (1,842 stars, GPL-2.0)
• Official website: https://oss.oetiker.ch/smokeping/