Octomon: When Ping Is No Longer Enough

Experienced network people have a comfortable set of old friends. ping answers one question. traceroute shows a path, or at least the part willing to answer. ss tells us about sockets. mtr watches the route over time. Add dig, iperf3, tcpdump, a Wi-Fi utility, and a few shell scripts, and eventually a picture appears.

This works. Some of us have been doing it long enough to type the commands before fully remembering why we opened the terminal.

Octomon takes a different approach. It collects many of those signals at once, places them in a btop-style terminal interface, remembers what happened, and tries to explain whether the problem is on the machine, Wi-Fi, gateway, DNS, ISP path, or remote destination.

It is not quite a must-have, because network engineers are perfectly capable of turning six terminals into one diagnostic instrument. It is, however, good enough that quite a few of us installed it after the first run.

Much more than four colorful pings

Octomon’s main screen contains four live panels and a short diagnosis of the connection. Behind that summary is a troubleshooting ladder that works outward from the machine:

link -> gateway -> DNS -> ISP path -> internet -> web -> destinations

Instead of reporting every failed check as an independent disaster, Octomon tries to rank causes above symptoms. If the gateway is unreachable, it does not need to announce ten remote hosts as ten separate outages. If a VPN came up seconds before latency changed, it records the timing as correlation without claiming the VPN definitely caused it. That distinction is small, sensible, and surprisingly rare in diagnostic software.

The Connection Quality panel continuously measures latency, jitter, packet loss, and percentiles against several well-known targets. On-demand speed tests add a bufferbloat grade. The panel can switch between ICMP and TCP connection timing on port 443, which matters on networks where ping is filtered. It discovers the gateway and early hops, runs a normal traceroute, or monitors the route in an mtr-like view.

The Bandwidth panel shows current throughput, speed-test results, network use by process, and traffic grouped by remote address. Speed tests can use Cloudflare, M-Lab, LibreSpeed, or an iperf3 server under your own control.

The Network panel brings together the active interface, connection type, IPv4 and IPv6 addresses, gateway, resolver response times, proxy settings, public addresses, and VPN state. On supported platforms it can also show Wi-Fi channel and signal information, nearby channel congestion, clock offset, NAT observations, path MTU, and outbound port filtering.

Finally, the Machine panel asks an important troubleshooting question: is the network slow, or is the computer too busy to notice that packets have arrived? CPU load, memory pressure, interface errors, thermal throttling, and busy processes are visible alongside the network measurements.

That is considerably more context than ping -c 20 can provide, through no fault of ping. It was never hired to investigate your Wi-Fi channel, DNS resolver, VPN route, and busiest CPU core at the same time.

It remembers the outage that disappeared

Intermittent problems have a habit of becoming healthy when somebody competent starts watching. Octomon addresses this with a timeline, persistent history, and a learned baseline for each network.

The session bar records healthy, degraded, and unavailable periods from the moment the program starts. Network changes such as joining Wi-Fi, roaming between access points, receiving a new address, changing a route, or enabling a VPN appear on the same timeline. Octomon can then report that the current latency is worse than usual for this particular network or that several outages happened during the same evening window.

For unattended observation, octomon --watch runs without the dashboard and prints findings when they appear and when they clear. It can send desktop alerts, call a command, or POST JSON to a webhook. The alert logic includes hysteresis, so one flapping link does not become a notification-based denial-of-service attack against the administrator.

There is also a short diagnostic mode:

octomon --doctor

It observes the connection for about 20 seconds and prints its analysis, measurements, recent events, history, and the learned normal for that network. --json produces machine-readable output. Sensitive details such as SSIDs, IP addresses, and MAC addresses are redacted by default, making the result much safer to attach to a support request.

Pressing D in the interface creates a support bundle containing the report, routes, events, configuration, and relevant data files. This fits nicely with our earlier advice on diagnosing packet loss and server connectivity: a reproducible symptom with timestamps and measurements is much more useful than “the internet was weird yesterday.”

IPv6, DNS, captive portals, and other fun

Octomon does not assume that successful pings mean a healthy connection. It checks HTTP reachability, TCP connections, resolver behavior, and both IP families.

It can distinguish broken IPv6 from broken IPv4, detect a captive portal, notice when web access fails while ICMP still works, and compare the system’s DNS resolver with public reference resolvers. It also checks whether a nonexistent domain returns the expected NXDOMAIN response instead of a helpful advertising page supplied by the network.

When normal HTTPS connectivity fails, an egress monitor checks several other protocols. Octomon also provides an on-demand outbound port scan covering services such as SSH, mail, DNS over TLS, NTP, and QUIC. These checks help separate “the connection is down” from “this network permits the web but blocks half the protocols.” On Linux, path-MTU probing can help identify the particularly entertaining class of failures where small packets work and larger ones quietly disappear.

None of this is magic. Some observations depend on what the operating system exposes, whether intermediate routers answer probes, and which helper tools are installed. Octomon generally tells you when it cannot measure something instead of inventing a confident result, which is exactly the right habit for a network tool.

macOS, Linux, and Windows

Octomon is open source, written in Rust, and available for macOS, Linux, and Windows on x86-64 and ARM64 systems.

On macOS, installation uses a third-party Homebrew tap:

brew tap securitypedant/octomon
brew trust securitypedant/octomon
brew install octomon

Debian and Ubuntu users can add the project’s signed APT repository. Other Linux distributions can use a static musl binary or install from crates.io. Windows packages are available through winget:

winget install SimonThorpe.Octomon

The complete and current commands are in the official installation instructions. Octomon is a young project moving quickly, so those instructions and the release notes should remain the source of truth.

Platform capabilities differ. macOS exposes almost everything Octomon needs without elevated privileges, although path MTU cannot be measured there. Linux may require a one-line ping-socket configuration for latency checks and elevated privileges to see bandwidth from every process. It also relies on tools such as traceroute, ss, nmcli, and iw; missing components are reported at startup. Windows currently lacks per-process bandwidth display and path-MTU measurement.

Octomon is designed to run without root and never asks for a password itself. Giving any monitoring tool elevated privileges should remain a deliberate choice, not muscle memory copied from a README.

What leaves the machine?

Network diagnostics necessarily generate network traffic. Octomon’s documentation is unusually explicit about every default destination, frequency, purpose, and data sent.

It pings public anchors, checks HTTPS and TCP connectivity, queries reference DNS resolvers, uses operating-system captive-portal endpoints, requests public IP information, and contacts octomon.dev/edge to show how the Cloudflare edge sees the connection. Optional speed tests and lookups contact their respective providers only when used.

The project says its edge endpoint stores no request logs or identifiers and that Octomon contains no other telemetry. The endpoint, IPv6 checks, speed tests, discovery, reference resolvers, and other probes can be disabled or replaced in the configuration. Local history is stored with owner-only permissions.

Administrators should still review those defaults before installing it on a restricted corporate network or a sensitive server. A transparent outbound request remains an outbound request, and security policies do not grant exceptions for attractive terminal interfaces.

It does not replace the old tools

Octomon is excellent at correlation and first-pass diagnosis. It does not inspect packet contents like Wireshark or tcpdump, replace a controlled iperf3 benchmark, explain every routing-policy decision, or make a filtered traceroute reveal silent routers.

When the dashboard points to packet loss after the fourth hop, we may still open mtr. When it shows a resolver behaving badly, dig gets its turn. When a socket behaves strangely, ss is still waiting exactly where we left it.

The difference is that Octomon helps choose the right old tool and gives it context. Instead of beginning with a guess, we begin with a map of the problem.

That makes it more than a pretty terminal dashboard, but slightly less than mandatory. We can live without it. Many of us have simply decided that we would rather not.