nethealth

A one-shot network check for the two problems you actually notice: video calls that freeze, and websites that load slowly.

Speed tests tell you your line is fast. They don't tell you why your call is breaking up. This measures the things that actually cause it — jitter, packet loss, and latency under load — and then says in plain words which one is your problem and whether to blame your wifi or your ISP.

Go standard library only, no dependencies, no root required.

Install

go install github.com/svandragt/nethealth@latest

No Go toolchain? Grab a prebuilt binary from the releases page.

Or build and install locally:

make install          # builds and installs to ~/.local/bin
make install PREFIX=/usr/local
make build            # just the binary, in place
make run              # build and run a full check
make quick            # build and run the fast check

Use

nethealth                              # full run, ~25s
nethealth -quick                       # skip the speed tests, ~8s
nethealth -site https://example.com    # time a specific site's page load
nethealth -no-color                    # plain output
nethealth -version                     # which build this is

Run it while things are bad. A clean result taken an hour later tells you nothing.

What it measures

| Section | What it tells you | | --- | --- | | wifi / router | Latency, jitter and loss to your own gateway. Separates a bad first hop from a bad ISP. | | internet path | The same to 1.1.1.1, falling back to 8.8.8.8 and 9.9.9.9. | | dns | A warm lookup, an uncached lookup (median across five zones), and the identical uncached test through 1.1.1.1 as a control. | | page load | DNS / TCP / TLS / first-byte breakdown of one real request. | | download, upload | Throughput, plus latency measured while the line is saturated. |

Then a verdict: separate lines for video calls and websites, where the fault lies, and what to change.

Notes on method

Jitter and loss matter more than speed. A 500Mbps line with 3% loss makes worse calls than a 20Mbps line with none. The verdict weights them that way.

Latency under load is the headline number. If your latency jumps by 100ms+ while something else is downloading, that is bufferbloat, and it's the usual reason a call freezes the moment someone else in the house does anything. The fix is a smart queue (cake or fq_codel) on the router, not a faster plan.

DNS is compared against a control. An uncached lookup is slow partly because of the authoritative servers, which is nobody's fault and not fixable by you. Running the same test through 1.1.1.1 cancels that cost out, so the tool only flags DNS when your resolver is genuinely behind. Five separate zones are sampled and the median taken, so one slow nameserver can't skew the result.

ICMP when it can, TCP when it can't. Real packet loss needs ICMP echo, which this does over an unprivileged datagram socket — no setuid, no sudo. If the kernel disallows it, the tool falls back to timing TCP handshakes and says so, because a retransmitted SYN can hide light loss. To enable ICMP:

sudo sysctl -w net.ipv4.ping_group_range="0 2147483647"

Gateway detection and unprivileged ICMP are Linux-only. Elsewhere it runs fine with the TCP fallback and skips the gateway test.

Throughput uses Cloudflare's public speed endpoints.