unsubbed.co

Meshping

Meshping handles ping any number of targets and collect response times as a self-hosted solution.

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

TL;DR

  • What it is: Open-source (MIT) network latency monitoring tool that pings multiple targets simultaneously and stores response times as histograms rather than averages [README].
  • Who it’s for: Network engineers, sysadmins, and technically hands-on founders running distributed infrastructure who need to know where packets are slowing down or dropping — not just that they are [README].
  • Cost savings: Commercial network performance monitors (ThousandEyes, Datadog NPM, PRTG) start at $100–$500+/mo. Meshping self-hosted runs on any Linux box with Docker and costs $0 in software license fees.
  • Key strength: Histograms instead of averages. When your average ping is 7ms but your RDP sessions keep dropping, a histogram shows you the 40ms tail that averages hide. Real data from the README shows this catching a misbehaving firewall that would have gone unnoticed with average-only tools [README].
  • Key weakness: Tiny project — 165 GitHub stars, one primary maintainer (Svedrin). No community reviews found from independent sources, no SaaS fallback, no alerting built in. You are betting on one developer’s continued interest.

What is Meshping

Meshping is a Docker-based network monitoring daemon. You point it at a list of targets (IPs or hostnames), it pings them continuously, and it stores every response time in a histogram database rather than computing a rolling average. The web UI at http://<your-ip>:9922 shows you those histograms, lets you run traceroutes, draws an SVG network map, and — the feature that makes it genuinely useful — shows you which hop in a traceroute went dark when something breaks [README].

The project description from the README is admirably plain: “Pings a number of targets at once, collecting their response times in histograms. Deploy at strategic points in your network to detect weak links and gain insight to your network’s topology.” That’s it. No pitch, no landing page, no freemium tier. It’s infrastructure tooling from someone who needed it and open-sourced it.

The “meshping” name is slightly misleading if you’re searching for it — the tool is a network monitoring utility, not a mesh VPN or mesh networking protocol. That conflation means most web searches for “meshping” return results about WireGuard topologies and ESP32 mesh firmware. Finding third-party reviews of the actual tool proved difficult because of this naming overlap; available community commentary is sparse.


Why People Choose It

No independent review sites have covered Meshping directly — the project is small enough (165 stars as of this writing) that it hasn’t attracted the benchmarking attention that tools like Uptime Kuma or Smokeping get. What exists is the README’s own documentation and the author’s public talk at Chemnitzer Linuxtage 2025, which gives a sense of the real-world problems the tool was built to solve [README].

The case for Meshping over simpler tools is histogram-based visibility. The README includes several concrete heatmap examples that are worth taking seriously:

The datacenter firewall incident: A customer’s infrastructure had intermittent RDP drops and inaccessible file shares. Average ping had climbed to 7ms — barely noticeable. But the histogram showed a clear cluster of packets taking 30–50ms, not 7ms. A firewall was “going bonkers” and delaying packets intermittently. Average-based tools would have shown “slightly elevated latency, probably fine.” The histogram showed “something is wrong, find it now” [README].

The WiFi point-to-point link: A kilometer-scale outdoor link showed most pings at normal latency, but a visible histogram cluster suggested occasional packet delay — possibly trees in the path causing signal obstruction [README]. This is the kind of signal that only appears in distribution data, not averages.

The design decision to store histograms instead of averages is the entire thesis of the project. Most network monitoring stores the mean or the 95th percentile. Meshping stores the full distribution. If you’re debugging a problem that affects 5% of packets, you need that distribution.


Features

Based directly on the README — no third-party validation available for feature accuracy:

Core monitoring:

  • Continuous ping of multiple targets simultaneously [README]
  • Latency stored as histograms, not averages — shows the full distribution [README]
  • Heatmap visualization over configurable time windows (default 3 days, adjustable via MESHPING_HISTOGRAM_DAYS) [README]
  • Multiple targets overlaid on a single graph for comparison [README]

Network topology:

  • Runs traceroute to map hops between your node and each target [README]
  • Generates an SVG network map from traced routes [README]
  • Path MTU discovery per hop — shows where packet size limits shrink [README]
  • AS (Autonomous System) information for each hop — useful for identifying which ISP or carrier a route crosses [README]
  • Routing loop detection with visual flag in the UI [README]
  • When a target goes down, nodes in the network map are colored to show where the outage is, even for hops that aren’t direct targets [README]

Operations:

  • Prometheus metrics endpoint (scrapeable) — integrates with existing Grafana dashboards [README]
  • Targets added and removed on-the-fly with no restart required [README]
  • IPv6 supported [README]
  • Peering: multiple Meshping instances can be linked to ping the same targets from different vantage points simultaneously [README]
  • Mobile-friendly web UI [README]
  • Docker images on Docker Hub [README]

What it doesn’t do:

  • No alerting built in — you’d wire that through Prometheus/Alertmanager
  • No authentication on the web UI out of the box — you’d proxy it behind something with auth
  • No SNMP, no agent-based monitoring, no log aggregation — it’s a pinger, not a full observability stack

Pricing: SaaS vs Self-Hosted Math

Meshping has no SaaS tier. It’s a self-hosted-only MIT-licensed tool. The cost math is simple:

Meshping:

  • Software: $0 (MIT license)
  • Infrastructure: whatever you’re already running Docker on, or a $5/mo VPS
  • Maintenance: your time

Commercial alternatives for context:

ThousandEyes (Cisco) — the enterprise-grade equivalent. Pricing is not public but starts in the thousands per month for multi-node deployments. Enterprise contract required.

PRTG Network Monitor — free tier covers 100 sensors. Paid plans start at $2,149/year for 500 sensors. Covers much more than ping (SNMP, bandwidth, etc.) but is Windows-primary and has a dated UI.

Datadog Network Performance Monitoring — $5/host/month plus platform fees. $50–$200/mo for a small infrastructure. Cloud-only, no self-hosting option.

Smokeping — the traditional open-source comparison. Also free, also self-hosted. Older codebase, RRDtool-based graphs, less modern UI. The main alternative if you want something with a longer track record.

For a small team running distributed infrastructure on 1–3 servers, the realistic comparison is Meshping vs Smokeping vs Prometheus + Blackbox Exporter + Grafana. All three are free. Meshping wins on setup simplicity and built-in network topology mapping. Prometheus + Blackbox wins on integration depth if you already have a metrics stack. Smokeping wins on proven longevity.


Deployment Reality Check

The README deployment path is three commands:

mkdir meshping && cd meshping
wget https://raw.githubusercontent.com/Svedrin/meshping/master/examples/docker-compose.yaml
docker compose up --detach

That gets you a running instance at http://<your-ip>:9922 [README]. It includes a Watchtower container that auto-updates Meshping — which is convenient but also means your monitoring tool can update itself without you noticing, which is a tradeoff worth knowing about.

What you actually need:

  • Docker and docker-compose (or Portainer)
  • A Linux host — the README also documents Raspberry Pi 4 and Windows via Docker Desktop/WSL2 [README]
  • For the Raspberry Pi path: Docker 19.03.9+ and libseccomp 2.4.2+ (there’s a known issue, see GitHub issue #30) [README]

What’s not in the box:

  • No authentication — the web UI is open by default. You’ll need a reverse proxy with auth (Caddy, nginx + basicauth, or Authelia) if this is on a public or shared network
  • No alerting — integrate with Prometheus + Alertmanager for that
  • No HTTPS — standard reverse proxy setup required for production

Realistic time estimates:

  • Technical user who’s deployed Docker containers before: 15–30 minutes to a working instance, plus another 30 minutes to add targets and read the traceroute output
  • Non-technical user: Meshping is probably not the right starting point. The tool assumes you know what an AS number is and have a reason to care about Path MTU.

The peering feature [README] — linking multiple Meshping instances to monitor the same targets from different network locations — requires running Docker on multiple hosts and editing configuration files. It’s documented but not one-command simple.


Pros and Cons

Pros

  • Histograms, not averages. The core design decision is correct. The firewall debugging example in the README is a real argument for why averages lie and distributions tell the truth [README].
  • MIT license. No usage restrictions, no commercial agreement, no “fair-code” gray areas. Deploy it, embed it, resell it.
  • Network topology map. The SVG map with AS information and outage coloring is unusual for a free tool — this is functionality that usually requires paid network monitoring software [README].
  • Path MTU discovery per hop. Niche feature that becomes essential when debugging mysterious packet fragmentation issues on mixed-MTU networks [README].
  • Prometheus scraping. Plugs into existing Grafana dashboards without extra work [README].
  • On-the-fly target management. Add or remove targets without restarting the daemon [README].
  • Genuinely simple deployment. Three commands and it runs [README].

Cons

  • 165 GitHub stars. This is a very small project. Small projects get abandoned. There’s one primary maintainer. If Svedrin stops maintaining it, you own whatever version you’re running.
  • No built-in alerting. You have to wire Prometheus + Alertmanager yourself, or build something custom. The tool shows you problems; it doesn’t tell you about them.
  • No authentication. The web UI has no login. This is fine for an internal network with firewall rules; it’s a problem if you expose it carelessly.
  • No independent reviews. At the time of writing, no tech publication, blog, or community site has reviewed Meshping specifically. You’re taking the README at its word.
  • Watchtower auto-update included by default. The default docker-compose ships with a Watchtower container that updates Meshping automatically. For monitoring infrastructure, silent updates are a liability.
  • Not for non-technical users. Understanding what the tool is showing you — AS numbers, MTU, routing loops — requires networking knowledge. It’s not a “is my website up?” tool; it’s a “where is my network degrading?” tool.
  • Narrow scope. Meshping does one thing. If you need uptime checks, SSL cert monitoring, HTTP response validation, or database health — you’ll stack this alongside other tools.

Who Should Use This / Who Shouldn’t

Use Meshping if:

  • You run a distributed infrastructure across multiple locations and need to understand inter-node latency and routing paths.
  • You’re debugging intermittent connectivity problems that don’t show up in average-based metrics.
  • You already have Prometheus/Grafana and want to add network latency histograms to your dashboards.
  • You’re a home lab user or sysadmin who wants Smokeping-level functionality with a more modern UI and topology mapping.
  • You want to deploy monitoring agents at multiple vantage points and compare their views of the same targets.

Skip it if:

  • You’re a non-technical founder looking for uptime monitoring. Use Uptime Kuma or Betteruptime instead — tools built for your use case.
  • You need alerting without building a Prometheus stack first.
  • You need HTTP, SSL, or service-level monitoring — Meshping only pings.
  • You’re not comfortable with Docker and basic Linux administration.
  • Project longevity matters to you. At 165 stars and one maintainer, Meshping hasn’t yet demonstrated the staying power of Smokeping or the community depth of projects like Uptime Kuma.

Alternatives Worth Considering

Smokeping — the established open-source latency monitoring tool. RRDtool-based, less visually modern than Meshping, but has a decade-plus track record and broad community documentation. If you’re not sure Meshping will be maintained, Smokeping is the conservative choice.

Uptime Kuma — if what you actually want is “is my service up?” monitoring with a clean UI, push notifications, and status pages. Different scope from Meshping but frequently what people searching for network monitoring actually need.

Prometheus + Blackbox Exporter + Grafana — the full observability stack approach. More complex to set up, but if you already run Prometheus, adding Blackbox Exporter gives you HTTP, TCP, ICMP, and DNS probes, plus alerting via Alertmanager. No topology mapping, but deeper integration with the rest of your metrics.

LibreNMS — full network monitoring platform with SNMP, ping, topology, and alerting. Much heavier footprint than Meshping (requires MySQL, PHP), but substantially more capable. Better choice if you’re monitoring network devices (switches, routers) rather than just hosts.

Zabbix — enterprise-scale open-source monitoring. Feature-complete for network and server monitoring with alerting, dashboards, and agent-based monitoring. Steep learning curve and complex setup, but genuinely robust.

ThousandEyes (Cisco) — if you’re at the scale where you need commercial SLAs, multi-cloud vantage points, and BGP route monitoring. Not comparable by price, but represents where Meshping’s ideas go at enterprise scale.


Bottom Line

Meshping is a sharp, focused tool that does one thing the right way: it stores network latency as distributions, not averages, and uses that data to show you where your network topology is failing. The firewall debugging example in the README alone makes a persuasive case for why histograms matter. The network map with outage coloring is genuinely useful functionality you don’t normally get for free.

The honest caveat is the project’s scale. At 165 stars and one primary maintainer, Meshping is a personal project that happens to be excellent — not a supported infrastructure product. If you adopt it, you’re betting on continued maintenance by someone who built it to scratch their own itch. For home labs, small distributed setups, and teams already running Prometheus, that bet is reasonable. For production infrastructure where monitoring tool stability is critical, stacking Meshping alongside a more established alternative is the prudent path.

If the Docker setup is the blocker, this is exactly the kind of infrastructure tooling that upready.dev deploys for clients — one-time, you own it.


Sources

  1. Piyush Aggarwal — “Mesh VPNs, and self-hosting” (Feb 5, 2024). https://piyushaggarwal.in/2024/02/05/mesh-vpns-and-self-hosting/ — piyushaggarwal.in
  2. Anurag Bhatia — “Self hosted open source mesh VPN with IPv6 support!” (Mar 2023). https://anuragbhatia.com/post/2023/03/selfhosted-mesh-vpn-with-ipv6-behind-cgnat/ — anuragbhatia.com
  3. NordVPN — “Connect devices securely with Meshnet”. https://nordvpn.com/meshnet/ — nordvpn.com
  4. Random Nerd Tutorials — “ESP-MESH with ESP32 and ESP8266: Getting Started”. https://randomnerdtutorials.com/esp-mesh-esp32-esp8266-painlessmesh/ — randomnerdtutorials.com

Primary sources:

Note: Sources [1]–[4] provided for this review cover mesh VPN and mesh networking topics generally, not Meshping the monitoring tool specifically. No independent third-party reviews of Meshping were located. Feature claims are drawn from the project README.

Features

Analytics & Reporting

  • Charts & Graphs

Security & Privacy

  • SSL / TLS / HTTPS