We measure the pipe, not what goes through it.

Collected

• Round-trip timings, loss counts and loss-run lengths for probes Helix sends
• Outage spans and the fault domain concluded for them
• DNS resolution timings and failures
• Total bytes in and out per connection, for usage and quotas
• Speed-test results, including the loaded-latency delta and bufferbloat grade
• Traceroute and MTR hop addresses when you run a path analysis
• Your public IP address, network operator and connection type, to identify which line a measurement belongs to
• Network adapter details and Wi-Fi signal strength, for local diagnosis
• Which applications used the network, and how much — kept on your machine, and never uploaded
• Once a day, a list of the names of the services this machine moved the most data to and from. This is on by default and there is a switch to turn it off; the section below says exactly what is in that list

Not collected

• The content of anything you send or receive
• Your browsing history — no page addresses, no times, no order, and nothing tied to you. The daily list of service names described below is deliberately none of those things
• How much data went to any particular service, or when. Volume decides which names make this machine’s list; it never leaves with them
• Which application talked to which service. Both are measured on your machine and neither is uploaded
• The addresses, names or hardware identifiers of other devices on your network. Helix reads your machine’s own neighbour table to list what is on the network for you, and none of it is uploaded
• Any packet Helix did not send itself — there is no traffic capture and no packet inspection

What is in the list

• A registrable domain, such as example-cdn.net, where a reverse lookup answers
• A network block, such as 104.18.32.0/24, where no name answers
• The date, to the day

What is not, and cannot be added later

• Byte counts. Volume ranks the list on your machine and stays there — how much you moved to a given service identifies you far more than the fact you reached it
• Times of day, or any timestamp finer than the date
• Application names
• Individual addresses, full paths, or anything from a URL
• Anything at all that ties a name to the machine that sent it

Short-lived where it is identifying

Your public IP is a connection attribute with a short life. The long-lived analytical record keeps the network operator and a coarse region, not the address itself — because what the analysis needs is “which ISP, roughly where”, and that is a much weaker identifier.

Redaction before publishing

A diagnosis report contains your IP, your ISP and the hostnames along the path. If you publish one, you are shown what it contains and can mask the last part of your public IP and hide hostnames — and the redaction is applied before the upload, not by hiding fields in the viewer afterwards.

Published reports

A published report lives at an unguessable link, is rate-limited, is marked not to be indexed by search engines, and can be revoked at any time. You can set it to expire.

Path hop countries are registry data

Each hop in a path analysis is annotated with the network that owns it and the country that network is registered in. That is not geolocation and it is not where the equipment is. We label it as registry country so nobody reads it as a location.

Gate one: consent

Did you turn sharing on for this link, and have you not withdrawn it? This is a live condition in the query itself, not a flag checked once and cached. There is nothing to expire and no job to wait for.

Gate two: scope

Which of your connections may this particular ISP see? For an ISP that operates its own network, that is the connections on their network. For a reseller or a carrier-grade-NAT operator without one, it is only the connection you explicitly pinned to them — and if you pinned nothing, they get nothing.

What they see

Latency, packet loss, outages and speed tests for the shared line, as counts and distributions over a window they choose, plus tickets you raised with them. They see your service ID because you gave it to them; they do not see your other connections, and there is no browsing or traffic data to see because none exists.

Their staff are limited too

Inside an ISP organisation, access is by capability rather than seniority. Their billing and CRM staff have no permission to read connection quality at all, because your consent was given for support purposes and a design that let a billing clerk browse your history would be a failed design.

What happens immediately

Turn sharing off in the dashboard and the very next request your ISP makes returns nothing for you. You disappear from their subscriber list entirely — not greyed out, not marked as revoked. An ISP has no business knowing that somebody used to share with it.

Every consent and every revocation is recorded as an immutable event, so what you agreed to and when is answerable.

Copies outside Helix

Telemetry is read from Helix per service and time-bounded. It is deliberately never bulk-exported into a database the ISP operates, because the moment a copy lives there, revocation stops being something the code enforces and becomes something a contract promises.

Where an ISP has legitimately retained something — a report you attached to a ticket, for instance — deletion is a contractual obligation on them, not a technical guarantee we can make on this page.

One policy, not three

The storage-limitation policy for raw telemetry is a uniform 45 days on every tier, free included, applied by an automatic sweep. The 3-, 30- and 45-day tiers are access entitlements: how far back the service will serve you. They are not deletion schedules and we never describe them as such — not to users and not to regulators.

The uniform window is not chosen separately from those tiers — it is the largest of them, read from the same table in code. It cannot drift below what a plan promises, because a test refuses to build a version where it has.

That is also why upgrading is instant rather than starting a new collection.

Summaries and account deletion

Downsampled summaries persist while your account is active and are deleted with the account. Delete the account and the local database on your machine is still yours — it is not reached by anything the cloud does, and you remove it by deleting the folder.

Data requests: [email protected]

Two third parties run on these pages

Secure Privacy provides the consent banner, and Google Analytics measures which pages people read. Both are loaded from their own servers, so both see your IP address and your browser’s user agent, as any embedded script does.

The consent manager loads first, deliberately. It decides whether the analytics tag is allowed to run, which only works if it is running before the tag rather than beside it.

What that is used for

Aggregate readership: which pages are found, which are read to the end, which are never reached. It is how a documentation page that nobody can find gets discovered and fixed.

It is not connected to your Helix account. Signing in happens on a different host, and nothing here is joined to a subscriber record.

Downloads are counted

When you download the installer, the request passes through a Helix-operated endpoint that records the time, the version, a coarse location derived from the address, and the address itself. That serves two purposes and only two: knowing how many people are running which version, and rate-limiting abuse of the download.

It is kept for 45 days, the same uniform window as everything else in this product, and then deleted. Why 45 days →

Your choice actually applies

Decline in the consent banner and the analytics tag does not run. You can change your mind from the banner’s control at any time.

The download counter and its rate limit are not analytics and are not covered by that choice: they are the operational record of a file transfer you asked for, in the same way a web server logs a request. We would rather say that plainly than bury it.