Understand
your connection

Every network you join is fingerprinted (Wi-Fi name plus the router's hardware address, so it survives address changes and mesh roaming) and gets its own baseline. Once a minute — but only when the connection is behaving — octomon folds that minute's latency, loss, DNS timing and signal strength into the baseline as a running average. After about five learned minutes the location is "established" and judgments become relative to its normal.

Minutes with an active problem never teach the baseline, so an outage can't redefine "normal". One refinement: a minute that is only latency-congested (a busy hotel evening) still teaches the honest parts — loss and signal — while its inflated round trips are discarded.

Because "is this bad?" depends on where you are. Latency and loss are graded against the location's learned normal, with absolute limits kept as floors. 200 ms at your fiber-connected office is a red flag; on a satellite-backed hotel network whose normal is 200 ms, it's just Tuesday. Plane Wi-Fi running 30% packet loss while the web still works reads as that network's weather — the same 30% at home is an incident.

The floors mean a clean network never gets graded leniently: learning only ever raises the bar for what counts as unusual, never lowers what counts as good.

No. A speed test saturates your link on purpose, so while it runs (and briefly after), octomon attributes the resulting loss and latency to its own test instead of raising alarms about the network. Bufferbloat measured under that load is still reported — that's the honest reading of the moment — but it's labeled as the test's doing.

Speed tests also teach: the result is stored per network (with the serving server), and becomes the capacity octomon compares your live traffic against when deciding whether congestion is self-inflicted.

Deliberately. The graphs are raw truth, updated every second. The analysis applies hysteresis: a finding must show up repeatedly before it raises, and must stay quiet for a stretch before it clears — with a grace period so a fault that flaps every half minute reads as one episode, not twenty. One dropped ping is not an outage, and an analysis that repainted itself every second would be noise, not judgment.

Almost certainly not — your router is ignoring pings addressed to itself while forwarding everything else perfectly, a common policy on airport, hotel and office networks. octomon checks the consensus: if targets beyond the gateway answer cleanly, every packet demonstrably passed through it, so the claim becomes a note — "gateway drops ICMP (forwarding fine)" — rather than a red alarm. A genuinely dead gateway takes everything behind it down within seconds, and that state does read as an outage.

It's the honest verdict for plane and hotel Wi-Fi: ping-based measurements look like an outage (heavy loss, huge latency), yet octomon's web check — a real HTTPS request, exercising DNS, TCP and TLS end to end — keeps succeeding. Working web traffic is direct evidence no amount of ICMP loss outweighs, so instead of crying outage the verdict says: expect slow pages and stalling calls, not a dead connection.

Routers answer traceroute probes with their control plane — the same little CPU that runs the router — and many rate-limit or ignore that work entirely while forwarding your actual traffic at full speed in hardware. If a hop shows loss but every hop after it is clean, your packets clearly made it through; octomon counts such hops as "silent" rather than blaming them. Loss is only pinned on the path when it begins at a hop and persists to everything downstream.

Because sometimes it's right to. octomon watches its host's own traffic per process, and when latency inflates while your machine is pushing a large share of the link's known capacity, the finding says so: "this machine is loading the link (mostly firefox) — likely self-induced bufferbloat". When your machine is quiet, it says that too, and points at other users or the access point. Blaming the network for your own ISO download helps nobody.

Three usual suspects: shared capacity genuinely changed (hotel evenings), the provider picked a different server, or a public test server was rate-limiting. octomon records which server ran each test and on which network — zoom the history (z) to compare like with like, and delete (d) results you know were the server's fault.

No. Baselines, incident history and speed-test results live in a local data directory on your machine; there is no account, no telemetry, no cloud. The only network traffic octomon generates is its own measurements — pings, DNS queries, HTTPS checks and the speed tests you trigger — and the README documents every endpoint it contacts and why. The --doctor report redacts addresses by default so it's safe to paste into an ISP ticket.