Networking Pingularity

Pingularity keeps the receipts on your internet connection

A self-hosted dashboard that probes your connection every few seconds and runs speed tests on a schedule, keeping outages, latency, DNS and bufferbloat in a SQLite file you own.

Pingularity is a self-hosted dashboard for your internet connection. One binary on a machine that stays on records outages, speed tests and latency, for as long as you want. It settles two arguments: whether the link dropped, and whether you get the speed you pay for.

How it watches

Every few seconds it opens ordinary TCP connections to several always-on landmarks (Google, Cloudflare and Quad9) over IPv4 and IPv6. One lost ping is never an outage: the dashboard flips to down only when a quorum of the landmarks agree, and only after two rounds in a row, so flaky Wi-Fi cannot fake an alarm and a real outage is timed to the second. IPv4 and IPv6 run as separate quorums, so an IPv6-only wobble reads as an IPv6 problem, not a dead internet.

The latency chart plots the lowest round trip across those anchors, five minutes to a month, with a second DNS line: each round resolves a random name against your real system resolver, so a struggling resolver reads differently from a dead link. The Connection panel adds your public IP, ISP, the resolver actually answering you, and the path out of your provider’s network.

Top of the Pingularity dashboard: status bubbles, the connection panel, a speed run with download, upload, ping, jitter and bufferbloat, and the per-anchor latency chart.
The top of the dashboard: connection facts, a speed run against your plan, and the per-anchor latency chart. Screenshot: Pingularity, from the project's README.

Speed tests

Download, upload, ping, jitter, packet loss and bufferbloat, tracked against your plan. Tests use Ookla’s servers by default or an iperf3 box of your own, run on demand, on a schedule, or after a reconnect; the drawer shows what a cadence costs in data. Bufferbloat gets its own readout: it pings before and during a run, and the difference is the lag a video call eats when a download starts. When your 500 Mbps line turns into 80 every evening at eight, that is a chart now, not a suspicion.

Alerts, exports and running it

Alerts go to a webhook (Discord, Slack, ntfy, Gotify, or anything Apprise can reach) with a heartbeat for an external watchdog, and there is a Prometheus endpoint with an official Grafana dashboard and alert rules, a JSON API, and CSV and full-database export. The database is one SQLite file on your disk, keeping 30 days of latency and a year of speed runs and outages by default.

It runs as one static binary on Linux packages that set up the systemd service, macOS, Windows or Docker, serving a web page on port 9000 that answers only its own machine until you turn on network access and set a login. It measures the host’s internet path, so run it on the machine whose connection you care about. Under Docker Desktop on Mac or Windows, even host networking rides a VM and the numbers describe the VM, not your line.

It is a young project: first commits in June, 85 commits in the last month, release 0.100.4, MIT licence. The exit traceroute needs a raw socket on Linux, and on IPv6-only hosts it shows as unavailable.

My read

The reason it earns a mention is what happens to the data. Hosted monitors keep your history in their account; this one hands you CSV, the whole database, a Prometheus endpoint and an API, so the evidence stays yours if you stop. Self-hosting, applied to the question every household asks weekly.

Source: pingularity.dev and the project repository.