How much data should an internet health monitor use?

A network monitor can easily become part of the problem it is trying to measure.

If it constantly downloads large test files, it consumes bandwidth, affects latency, and makes its own measurements harder to trust.

A useful internet health monitor should therefore separate lightweight observation from heavy active testing.

Background checks should answer small questions

Onlink’s core reachability monitor uses small HTTPS HEAD requests. It normally checks Apple’s website and uses Cloudflare as a fallback if the first target fails.

Those checks run periodically and when macOS reports a network-path change. They are designed to answer a narrow question: does the internet appear reachable?

Internet Health also uses lightweight evidence for latency, jitter, failed checks, and incident state.

The goal is not to saturate the connection.

A speed test answers a bigger question and costs more data

Throughput tests need to move enough traffic to estimate capacity.

Onlink supports explicit Cloudflare and M-Lab tests, and the app warns that a test may transfer substantial data depending on the connection.

M-Lab also has its own privacy model: its measurement and client public IP can be retained and published in its public dataset, which is why Onlink requires consent before the first M-Lab test.

Those are very different behaviors from a tiny reachability check.

Heavy tests should never be a surprise

Onlink does not silently launch a full speed test when Internet Health detects a problem.

Automatic incident diagnosis uses lightweight Wi-Fi, gateway, DNS, direct internet, IPv6, and HTTPS evidence instead.

Manual Diagnose can go deeper, including a brief loaded-responsiveness transfer, but that happens because the user explicitly chose Diagnose.

This design keeps the background monitor from changing the network conditions it is trying to observe.

Pause overlapping measurements when needed

A full speed test deliberately loads the connection. Running ordinary background probes at the same time could make those samples look worse for a reason created by the app itself.

Onlink pauses its main lightweight connectivity monitor during a full speed test.

That separation is as much about measurement quality as data usage.

Local storage is not network upload

Keeping a history on disk does not mean sending it to a server.

Onlink stores its health history locally in the app’s sandbox and has no Onlink account or Onlink backend. Health samples and incidents are retained locally for up to about 90 days; raw connectivity probes use a shorter window.

The optional public-IP/provider lookup is separate and disabled by default.

The Privacy Policy lists the exact external endpoints and retention behavior.

Judge a monitor by what it does while you ignore it

The best test of background software is what happens when you leave it alone.

A health monitor should:

• create small, predictable network activity;
• avoid continuous throughput tests;
• avoid uploading local history to its developer;
• make bandwidth-heavy actions explicit;
• preserve enough evidence to explain incidents later.

That is also why reliability and speed need separate tools.

Monitoring should help you understand the network, not become another major source of traffic on it.