Where did octomon get its name?

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.

The performance line in the analysis (and the word in the footer) is the deliberate opposite of everything above it: it ignores the location's learned normal entirely and grades the same measurements on one universal scale. Four components are graded: latency (the median across the anchor targets), jitter, packet loss, and bufferbloat once a speed test has measured it, each into excellent / good / fair / poor at fixed steps: latency at 50/150/300 ms, jitter at 10/30/80 ms, loss at 0.5/2/5%.

The overall grade is the worst component, because one bad dimension is what you feel: 80 ms of jitter ruins a call no matter how clean the loss number is. The two readings answer different questions on purpose: every rung can be green ("nothing is wrong for this network") while performance reads poor ("…and this network's normal is still a bad place to take a video call").

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.

No. Plenty of hosts never answer ICMP at all: game servers, cloud VMs, load balancers. The game or the site works while the ping column sits at 100%. Only the built-in anchors (1.1.1.1, 8.8.8.8 and 9.9.9.9, chosen because they answer pings from anywhere) vote on whether the internet is reachable. A target you add is judged on its own against that consensus: one that has never answered a ping on this network reads "doesn't answer pings, your connection is fine" as a note, and the destinations rung lists it under "never answered pings". A target that answered and then stopped is a different story, and does read as that host having gone away.

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.

A network where every ping goes unanswered is a different case: that is ICMP dropped as policy (Azure VMs and some office networks do this), and the loss columns are measuring the policy, not the connection. octomon then says so in the analysis ("no ICMP here") and judges on the web check, DNS and its TCP connect probes instead, which can read perfectly healthy.

That is the state that reads as a dead internet, and on a filtered network it is wrong: an office or guest network that blocks port 443 takes out pings, the TCP connect probes and the web check at once while SSH, NTP or DNS still get out fine.

So the thing octomon watches is port 443 itself: when its TCP connect probes to every anchor stop answering, whatever pings and plain HTTP are doing, it looks for proof the path is up. Its reference resolvers (1.1.1.1 and 8.8.8.8 by default, over UDP 53) are already being probed; one of them answering is a packet crossing the internet and back. It also starts an egress monitor: a five-row list (HTTP on port 80, QUIC, SSH, NTP, DNS, each against a host that reliably answers) probed every 5 seconds until port 443 comes back. The monitor announces itself on the timeline, has its own row in the analysis, and can be turned off with egress_monitor = false; the hosts are yours to change in egress_monitor_checks.

With that evidence the analysis says "web blocked on this network, SSH, NTP and DNS get out" instead of "internet unreachable", the session bar shows amber rather than red, and the Connection Quality table switches to the monitor's rows so there is still a live view of what the connection can do. Port 80 open while 443 is dead gets its own wording: that is the signature of a filter that only allows what it can inspect.

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.

Because a resolver can be quick, answer every query, and still be lying, and no amount of timing will tell you. Once a minute octomon asks each resolver for a made-up name under the probe domain (octomon-nx-3f0a91b2c4.example.com, stamped with the clock so nobody can have it cached). That name provably has no address, so the only honest reply is NXDOMAIN, "no such domain". An address back means the resolver invented one, and is redirecting your misses to a search or ad page.

It matters because plenty of software depends on a name failing to resolve. Typing a single word in a browser bar reaches your search engine only because the lookup fails first; failover logic that tries a name, expects nothing, and moves on will instead connect to whatever was invented, and hang. What the user reports is never "DNS is broken", it's "the internet is weird sometimes".

It matters to the analysis too: without this probe a hijacking resolver looks perfect. Fast answers, no loss, a green rung, while DNS quietly lies. The comparison also names who is doing it. If only your own resolvers redirect, that's your ISP monetising your typos. If the public reference resolver comes back redirected as well, nothing is reaching the resolver you asked for at all: this network is intercepting port 53, which is a captive portal or a transparent redirect, and a much bigger deal.

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.