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 is a point on a map, placed by IP geolocation, 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 plotted over time. You can switch to an ASN view β hops grouped by autonomous system (BGP/ASN), showing exactly which providers your traffic transits.
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 (0)