When a link starts flapping and a client messages "everything is slow," the question is always the same: is it your network, the ISP's link, or something further down the path? Here's PULSAR, a self-hosted network monitor that answers it β without sending your traffic anywhere else.
testsia
/
pulsar-monitor
PULSAR β self-hosted, real-time network monitoring (Ping/MTR/Traceroute/HTTP/DNS/TCP), alerting, incident correlation, route geo-analytics
PULSAR
π¬π§ English | πΊπ¦ Π£ΠΊΡΠ°ΡΠ½ΡΡΠΊΠ°
π§ Active development. Expect breaking changes between releases. Found a bug or have an idea? Open an issue or start a discussion β and if PULSAR is useful to you, a β star helps others find it.
Self-hosted, real-time network monitoring. Ping, MTR, Traceroute, HTTP DNS, and TCP probes against any host or agent, with alerting, incident correlation, route/ASN geo-analytics, and a live WebSocket dashboard β no polling, no external SaaS dependency, your data stays on your own infrastructure.
More screenshots (monitor list, RTT history)
Features
- Multi-protocol probing β ICMP Ping, MTR, Traceroute, HTTP(S), DNS, TCP each with its own configurable interval/timeout/thresholds
- Live dashboard β WebSocket-pushed monitor states, RTT/loss/jitter charts, no client-side polling
- Alerting & incident correlation β one alert per real-world incident (not one per flapping probe), automatic root-cause grouping by shared route/ASN topology, Telegram notifications
- Route intelligence β historical route playback, animatedβ¦
βΆοΈ Watch the full walkthrough on YouTube
PULSAR is a self-hosted network monitoring system you run on your own infrastructure: multi-protocol probes against any host, a live dashboard with no polling, alerting with incident correlation, and route geo-analytics. No external service, no target-count license tiers, no telemetry leaving your network β the data stays exactly where you put it.
If you've reached for PingPlotter, SmokePing, or WinMTR for latency and traceroute monitoring, or you're comparing self-hosted network observability tools for a homelab or a small ISP/MSP's netops stack, PULSAR is built to cover the same ground β ping monitor, traceroute tool, MTR, and route/BGP-ASN analytics β in one open-source package.
Here's a tour of the interface, screenshot by screenshot.
Install in three commands
The whole system is one stack: a FastAPI backend, the frontend, TimescaleDB on top of Postgres, a dedicated worker for ICMP probes, and a garbage-collection worker.
git clone https://github.com/testsia/pulsar-monitor
cd pulsar-monitor
cp .env.example .env
docker compose up -d
Five containers come up β open it in a browser and log in with the default credentials from .env.example: admin / changeme (change this before exposing the instance to anything but localhost). Auth is session-cookie based, with admin, operator, and viewer roles.
The dashboard: your network's state at a glance
The main screen shows counters for healthy, down, and unstable monitors, plus rankings for who currently has the worst latency, packet loss, and jitter. Every tile is clickable and drops you into an already-filtered list.
The part that's hard to convey in a screenshot: it updates itself. Data arrives over WebSocket the moment each probe finishes β no browser polling, no lag.
Monitors: six probe types
- Ping β plain reachability and RTT.
- Traceroute / MTR β the full path to the target, with per-hop RTT.
- HTTP / HTTPS β status code and response time.
- DNS β resolve time.
- TCP β reachability of a specific port.
Each monitor has its own interval, timeout, and thresholds. If you run multiple sites, probes execute from a dedicated agent and the monitor is bound to the right one. The table can be sorted, but by default it doesn't reshuffle on every tick, so a row won't run away from under your cursor.
History and automatic anomaly detection
Clicking a monitor opens its detail view: a chart of RTT, packet loss, and jitter over the selected period, with drag-to-zoom. The chart carries two kinds of markers: an anomaly, when RTT sharply left its normal band, and a route change, when traceroute showed a different path.
The baseline is computed automatically β a z-score over TimescaleDB's hourly roll-ups. "Anomaly" means a deviation from this specific monitor's own history, not some fixed threshold applied across the board.
Routes: map, ASN, historical playback
The Routes section shows how traffic actually reaches a target: every hop, with RTT and loss on that specific segment β the same kind of hop-by-hop trace you'd get from traceroute, mtr, or WinMTR, but stored and correlated over time. You can switch to an ASN view β hops grouped by autonomous system (BGP/ASN), showing exactly which providers your traffic transits, and a geo map placing each hop by IP geolocation.
Historical Playback is a time slider: drag it back and the route redraws as it looked an hour or a day ago. And the flapping detector catches a route bouncing back and forth β five changes in ten minutes collapse into a single alert instead of twenty separate ones.
Alerts that don't drown you
When a monitor crosses its thresholds, an alert is raised. But the point isn't the number of alerts β it's not drowning in them. PULSAR groups them: one real alert per real problem, not one per bounce of a flaky probe.
Incidents: correlation and root cause
The Incidents section goes a step further than plain alerts. If ten monitors drop at once and they all route through the same ASN or a shared hop, that's one incident with an identified probable cause β not ten separate alerts. The system shows exactly what the affected monitors have in common: a likely culprit hop, with a confidence percentage.
Critical events go straight to Telegram, with a link to the specific monitor.
Comparing channels head to head
If you have two internet uplinks, a dedicated section compares them directly: one target, probed over two different physical interfaces. Both routes on one map, in different colors, with the points where the paths diverge highlighted. The Channel Stability Analyzer gives a deterministic score β no AI, just statistics over the history β for which channel is steadier on RTT, loss, and number of route changes.
Geo-analytics and topology
Geo Analytics collects hops from every route of every monitor onto one heatmap and colors them by a metric β RTT, loss, or jitter. You immediately see whether a problem is local to one monitor or an entire region is hurting β the same "where does it actually hurt" question PingPlotter's route map tries to answer, but aggregated across every monitor at once.
Topology shows the same thing as a graph: shared hops become nodes, and you can see where many routes converge on a single point β that point becomes a single point of failure, and it's the first thing PULSAR suspects during a mass outage.
Backups, atomic restore
Back up the full system or just the configuration, downloaded as a single file. Restore is atomic, in one transaction: if anything goes wrong, the database is left exactly as it was. Before a restore, the system takes a fresh backup of the current state on its own, just in case.
One stack, your data stays yours
PULSAR is self-hosted and open source (MIT), under active development. No limit on how many targets you monitor, and no external service you have to trust with your traffic β whether you're running it for a homelab, an MSP's netops dashboard, or infrastructure monitoring for a small ISP.
- β GitHub β testsia/pulsar-monitor
- βΆοΈ Full walkthrough on YouTube
- π³ Docker Hub
Top comments (3)
Nice scope. One useful guardrail for this kind of dashboard is to separate reachability from path quality: an ICMP loss percentage alone can be misleading because routers often rate-limit or deprioritize ping. Iβd compare a stable TCP/HTTPS probe to the same destination and treat MTR loss as meaningful only when it continues at later hops or reaches the endpoint.
For incident triage, I also like recording the resolver, connect, TLS, and first-byte timings separately. That makes it much easier to tell DNS trouble from a slow application or a congested link instead of collapsing everything into one latency number.
Both points are spot on, thanks for this.
The ICMP-loss caveat is real β MTR loss on an intermediate hop is often just a router deprioritizing/rate-limiting ICMP, not an actual problem. Right now PULSAR's flapping/anomaly detection leans on the target-level probe (ping/traceroute reaching the endpoint), but I don't have an explicit "only trust loss if it persists to later hops or the destination" rule surfaced in the UI yet β that's a good sharpening of the root-cause logic.
On the phase breakdown: you're right that the HTTP probe currently reports one response-time number. Splitting resolver/connect/TLS/TTFB is a legitimate gap, not something already there β going to open a GitHub issue for it, it's a natural fit for the existing HTTP probe.
Thanks, this is great feedback β both points landed.
On the phase-separated timings: implemented it today. HTTP/HTTPS probes now report dns_ms, connect_ms, tls_ms, and ttfb_ms separately instead of one duration number, exactly for the reason you mention β a single figure was hiding whether the problem was DNS, the handshake, or the app itself. Real socket/TLS timing under the hood, no more stubbed 200/0ms.
On reachability vs. path quality: half of this was already the design β MTR-based alerts only fire on loss that reaches the actual destination, not on loss at a single interior hop, specifically because routers along the way do rate-limit/deprioritize ICMP. So a hop that looks lossy mid-path but where the destination still responds cleanly won't trigger anything.
What we don't have yet is your first suggestion β actively cross-checking an ICMP-based monitor's result against a parallel TCP/HTTPS probe to the same destination before treating loss as "real." That's a genuinely useful guardrail and a fair scope gap on our end; it's going on the roadmap as a follow-up (correlating monitors by shared target across probe types, not just within one monitor's own history).
Appreciate you taking the time to write this up β it directly shaped what shipp