Smokeping

Last reviewed Sep 13, 2026 · 761 words

SmokePing settles the argument with your ISP. Every 5 minutes it sends 20 pings to each host you list, then plots the median as a line and the spread of all 20 as grey smoke around it, with lost pings as colour. A connection that "feels slow" shows up as a widening smoke band at 8 pm every evening, and that graph is evidence a support desk accepts. It has done this since 2003, it is written in Perl, it runs in about 128 MB, and no newer tool has replaced the smoke plot.

Read the smoke, not the line

The median line tells you round-trip time; on its own it is boring. The smoke is the interesting part. A thin dark band means 20 consistent pings, which is a healthy link. A wide grey fan means jitter: the same 20 pings came back with wildly different times, which is what makes video calls stutter even when average latency looks fine. The colour of the median marks loss, green for none shading to red for heavy. Once you have watched a target for a week you can spot a congested uplink, a flapping Wi-Fi mesh node, or a bufferbloat-prone router at a glance, and you can put the graph next to a speed test to show that bandwidth was never the problem.

Run the linuxserver container

Installing from distribution packages means wrestling Apache, FastCGI and Perl modules. Skip it.

services:
  smokeping:
    image: lscr.io/linuxserver/smokeping:latest
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London
    volumes:
      - ./config:/config
      - ./data:/data
    ports:
      - "8080:80"
    restart: unless-stopped

The web UI comes up on port 8080 with a demo set of targets. All the RRD files land in /data, and they are small: a target costs a few hundred KB regardless of how long you keep it, because RRDtool consolidates old data instead of growing. Back up /config; /data is nice to keep for history but not critical.

Targets is the only file that matters

Everything you will ever change lives in /config/Targets. The syntax is a plus-sign hierarchy:

+ ISP
menu = ISP
title = Upstream

++ Gateway
menu = Gateway
title = Router WAN side
host = 192.168.1.1

++ Cloudflare
menu = Cloudflare
title = 1.1.1.1
host = 1.1.1.1

Restart the container after editing and new graphs appear in the sidebar within one polling cycle. The useful set for a home connection is 4 targets: your router, your ISP's first hop (from traceroute), a public resolver, and one service you actually care about. Comparing them tells you which segment is at fault when things degrade. Touch the Probes file only when you want more than ICMP: the DNS probe measures resolver response time, the Curl probe measures HTTP fetch time, and there are SSH, LDAP and SIP probes for the people who need them.

Alerts fire on patterns, not thresholds

The alerting is smarter than the UI suggests. Instead of "latency over 100 ms", you write a pattern over recent samples:

+someloss
type = loss
pattern = >0%,>0%,>0%
comment = loss on 3 consecutive rounds

+rttdoubled
type = rtt
pattern = <100,>100,>100
comment = latency jumped and stayed

Alerts go to email by default or to any script you name, which is how you bridge them to ntfy or a chat webhook. Set them after a week of baseline data, not on day one, or you will alert on what normal looks like.

Next to Uptime Kuma, LibreNMS and Grafana

SmokePing is single-purpose. It will not tell you a disk is full or a service is down; for that you want Uptime Kuma for reachability or LibreNMS if you have SNMP-speaking gear. Grafana users sometimes ask whether to replace SmokePing with a Prometheus blackbox exporter and a histogram panel. You can, and you get nicer dashboards, but you lose the 20-samples-per-point density unless you scrape every 15 seconds, and you spend an afternoon rebuilding what SmokePing gives you in 10 minutes. Keep it as the specialist alongside the general monitoring stack.

What I'd do

Run the linuxserver container on whatever box is always on, point it at 4 targets, and leave it for a month before deciding anything. The UI looks like 2005 because it is, and it does not matter. The next time your connection misbehaves you will have a graph with a timestamp instead of a feeling, and that is the entire reason 1,964 people starred a Perl CGI script.