01 Early Access

SmokePing-Style Monitoring That Names the Broken Link

A small prober pings every device on your network map twenty times every five minutes and draws the familiar smoke chart. ISPbox then compares hosts to find the link that is losing packets, says what is most likely wrong, and opens an incident for the customers behind it.

  • Latency spread and loss per host, per link and per customer device
  • A diagnosis with evidence and next steps, not just a red graph
  • Device logs from MikroTik and other gear in the same place
Smoke chart of latency and packet loss next to a network map with one link highlighted
// In the product

Path monitoring in the product

Real screens from the product.

The smoke chart you know

Latency spread as grey bands and the median as a line coloured by loss, for any host, over hours, days or weeks.

Smoke chart with latency spread and median line coloured by packet loss

A diagnosis, not a guess

Each problem is one card: what is wrong, how sure the system is, the measurements behind it and what to check first.

Diagnoses feed with a link fault, its evidence and suggested next steps

The whole network at a glance

Hosts up, links healthy, loss over the last day and open incidents, with the topology drawn from your map.

Monitoring overview with network health strip and topology
→ Under the hood

How it works

SmokePing is the tool many ISP engineers trust for latency and loss, but it only draws graphs: somebody still has to work out which hop is to blame and who is affected. ISPbox path monitoring keeps the smoke chart and adds that second half, using the network map you already maintain.

The prober

The prober is one small container that runs on a Linux server in your network or in a container on a MikroTik running RouterOS v7. It sends 20 pings per target every 5 minutes by default, and also supports TCP, HTTP and DNS checks and an hourly traceroute to internet reference targets. It stores results in its own local archive before sending them, so nothing is lost while your uplink is down, and it has a local status page for when the panel is unreachable.

From hosts to links

Targets come from the ISPbox network map: every device with a management IP and every customer device behind it. ISPbox knows which links each measurement crosses. It compares each host with its own normal latency for that time of day, and when every host behind a link is worse while hosts that do not cross it are clean, the link is marked as the probable cause. Optional SNMP counters on link ends show whether the link is simply full.

Diagnoses and incidents

A rules engine checks eleven kinds of problem, including a faulty link, saturation, radio degradation, a power outage, a customer-side fault, an upstream ISP problem and slowly rising latency. Each diagnosis carries its confidence, the evidence and recommended next steps; it never changes a router by itself. A degraded link opens an incident for everyone downstream, and alerts use hysteresis so a single bad cycle does not page anyone.

Device logs

The prober also receives syslog from your devices, classifies lines from MikroTik and other vendors into events such as link down, config changed, reboot or DFS radar, and uses them as evidence: a config change right before the loss started is shown next to the diagnosis. MikroTik routers managed over the API can be set up to send logs with one button.

Works with Network Monitoring, Network Maps, AI Assistant (MCP)

02 Why this feature matters

Built for high-speed ISP operations

Links, Not Just Hosts

When hosts behind one link degrade and hosts that avoid it stay clean, ISPbox marks that link as the likely fault.

Targets From Your Map

The prober reads its targets from the ISPbox network map and the services on it. There is no separate target file to maintain.

Data Stays on Your Side

The prober keeps its own archive on your server and ships it when the uplink is back, so an outage does not leave a gap in the charts.

Tied to Customers

A degraded link opens an incident with the customers behind it, and the diagnosis shows on the client page and in tickets.

03 Use cases

Where ISP teams put this to work

  • Find which backhaul hop is dropping packets when a whole sector complains.
  • Tell a customer whether the problem is their radio or your network.
  • See a config change in the router log right before the loss started.
  • Replace an old SmokePing box with charts your whole team can open.
// Related

What ISP and WISP teams search for

smokeping alternative smokeping packet loss monitoring network latency monitoring isp network monitoring wisp link monitoring mikrotik syslog server
04 FAQ

Frequently asked questions

Is this available to every ISPbox customer?
Path monitoring is in early access and is being switched on for workspaces one at a time. Write to [email protected] if you would like it for your network.
Does it use SmokePing or RRDtool underneath?
No. The prober and the charts are written from scratch. It follows the same idea (many pings per cycle, the full spread of results), but stores the data in ISPbox so it can be linked to your map, customers and tickets.
Where does the prober run?
On any Linux server with Docker inside your network, or in a container on a MikroTik router with RouterOS v7. One prober can watch a few thousand targets.
Do I need LibreNMS or Zabbix for this?
No. Path monitoring works on its own from your ISPbox network map. If you already use LibreNMS or Zabbix, those integrations keep working next to it.

Know Which Link Is Broken

Create a workspace and map your network, then ask us to switch on path monitoring for it.