I built LibrePing — decentralized uptime monitoring on a libp2p mesh
Commercial uptime tools are great until you care about who sees your check targets, or you want vantage points you actually control. I wanted something closer to a community mesh than a SaaS control plane.
What LibrePing is
LibrePing is AGPL-3.0, written in Go, and uses libp2p so hubs gossip checks and results peer-to-peer. Probes run HTTP(S), TCP, DNS, TLS cert, ICMP, and traceroute checks from wherever you put them.
Highlights:
- No central company server for the mesh
- Deduplicated checks (same URL added by many people is monitored once and shared)
- Browser key = account (no signup); recovery phrase
- Signed everything; sealed alert destinations (ntfy / Discord / Slack / webhook)
- Probe failover across hubs
Live demo (no signup): https://nl.lp.mw.gg
Repo: https://github.com/mwgg/LibrePing
git clone https://github.com/mwgg/LibrePing.git
cd LibrePing
docker compose up -d --build
# open http://localhost:8081
Why libp2p
Gossip + anti-entropy means a hub that joins late can catch up instead of only seeing new traffic. Results are sharded across hubs so the network can grow without every node storing everything.
What I want feedback on
Probe trust / abuse resistance, alert UX, and whether hub operators would actually run public entry points. Issues and PRs welcome.
Top comments (1)
On probe trust: one pattern that works well is requiring agreement from a few probes on different hubs (ideally different networks) before a check flips to down, and scoring each probe by how often it disagrees with the majority. A broken or lying probe then loses weight instead of paging people at 3am.
For abuse, the dedupe helps, but since keys are free, a rate limit per target domain rather than per account is what stops the mesh from being pointed at someone's site. Does a hub currently weight results from a probe it has never seen before the same as a long-running one?