Documentation
From a bare Windows machine to an agent that is measuring and syncing. Your own provider sees your line only once it has proved it runs your network, and one switch turns that off. Each step says what success looks like, so you can tell whether it worked.
The three pieces
Helix is a background service, a desktop app, and an optional cloud account. The seam between them is worth understanding once, because most confusion is really a question about which piece is doing what.
- The service does every measurement and owns the local database. It starts with Windows and runs whether or not anyone is signed in.
- The desktop app is a viewer. It connects to the service over a local pipe and starts nothing; closing it stops nothing.
- The cloud account is optional. Without one, the agent still measures and still diagnoses — you just have no history across devices and nothing to share.
1. Install the agent
Download the installer and run it. You will see a SmartScreen warning because it is not code-signed, and an administrator prompt because it registers a service. Both are explained in full on the download page — please read that before clicking through, rather than after.
You should see:
- Helix Internet Monitor in Start Menu and in Add/Remove Programs.
-
A service called
HelixCoreService, state Running, startup type Automatic. Check withGet-Service HelixCoreServiceif you want to be sure.
2. First run
Open the app. It should show your active connection identified by network operator within a few seconds — that is the app successfully talking to the service. Measurement windows begin accumulating immediately.
Numbers will be sparse at first, and the interface will say so rather than pretending otherwise. The canonical loss window is five minutes at one probe per second, so a loss figure worth trusting is about five minutes away; before that it is labelled coarse. Give it an hour before drawing conclusions about anything intermittent.
From the first start the agent also contributes its measurements anonymously — under your network’s provider, with nothing that names you or this computer — so the public rankings and your provider’s figures include your line. Settings → Privacy & sharing turns that off. Connecting the device to your account, in step 4, replaces the anonymous contribution with your own history.
3. Create an account
Go to monitor.helixaicloud.com and register with an email and password, or with Google. This account is what gives you history beyond the local machine, your links to providers, and tickets.
A new account is on the free tier. Free reads back 3 days, Pro 30 and Enterprise 45. Measurements are kept for 45 days on every tier — the longest any tier can read, as the privacy page sets out — so if you upgrade later the history is already there.
4. Connect this device
- In the desktop app, open Settings → Account and press Sign in with your browser.
- Your browser opens the console. Sign in there and approve this computer; the code on the page should match the one the app shows. The request lasts ten minutes, and closing the app’s window does not stop it.
You should see: Settings → Account says this computer’s measurements go to your account, with the time of the last accepted upload, and the console’s Devices list shows the machine with a recent last-seen. Any windows the service already measured upload as a backlog, so a machine that has been running for a while populates its history rather than starting from now.
No restart is needed at any point — the service watches the stored credential and starts syncing in place. Disconnect…, in the same place, stops the uploads; the computer keeps measuring.
A computer that cannot open a browser, or one that reports to a different Helix server, uses a device token instead. In the console, open Devices → Advanced: a device token and choose Issue a device token. Then in the app open Settings → Account → A different Helix server, or a device token, paste it, and press Connect with this token. The token is shown once — the server keeps only a one-way digest of it, so it can be replaced but never recovered.
5. Share with your ISP
Your own provider sees your line only once it has proved to Helix that it runs your network, and one switch turns that off. When your line is on the network of a provider that has proved it runs it, a link to that provider is made for you with sharing on. A link you add yourself starts with sharing off. Once sharing is off, nothing but you ever turns it back on.
To link a provider yourself, with the account number they know you by:
- In the dashboard, find your ISP and enter the account or service number they issued you. It is validated against the format that ISP registered, so a typo is caught rather than silently linking you to nothing.
- Choose which connection the link applies to. If you run Helix on more than one line, only the one you pin is in scope.
- Turn sharing on for that link.
What they see while sharing is on: latency, jitter, loss counts, outages, speed tests and path traces for that line. Not your browsing, not what you use the connection for, and not which applications used it — that stays on your computer.
Besides the measurements, a few things leave your computer for Helix rather than for any provider:
- Once a day, a list of the services it uses most: a name where one is known, otherwise only the address’s network block, with nothing attached. Helix counts them to rank the most-used hosts on NETStats. It is on by default, and it has its own switch.
- The agent’s own warnings and crash reports, scrubbed of addresses and names, sent with the measurements.
- Anything you send, such as a report to your account (an assessment or a sweep you start sends one unless you untick its box) or feedback. A report reaches your provider only if you attach it to a ticket or send them its link.
Settings → Privacy & sharing in the app lists every one, and the switch that governs it.
Turning it off: flip sharing off and their next query returns nothing. There is no cache to expire. You disappear from their subscriber list entirely rather than appearing as revoked. More on revocation →
6. Raise a ticket
Once a link exists, you can open a ticket with your ISP from the dashboard. It arrives in their portal tagged with the service ID they know you by and, while sharing is on, alongside the live quality view for your line, so the conversation starts from evidence rather than from “when did this begin”.
The ticket form can attach a diagnosis report you have sent to your account. If your provider takes tickets by email, the notice carries its headline and verdict, plus a link to the full report if you published it before raising the ticket. That link stops working once you revoke it, or after its 30 days. Their portal shows only the report’s reference, so if they need the full report, publish it and send them the link.
7. Run a diagnosis
The Link Troubleshooter, under Diagnose → Line diagnosis in the app, runs twelve stages (thirteen with the speed test) from your network adapter out to the destination and produces a verdict with its confidence, the evidence supporting it, and the evidence arguing against it. Run it on demand, whenever you want an answer.
It takes up to about three minutes with a speed test, under a minute without. Stages that cannot run — the Wi-Fi radio stage on a wired machine, for instance — are reported as skipped with the reason, never quietly dropped.
When it finishes you can save the report as a web page, which goes to the Helix Output folder in your Documents, or send it to your account and publish it from the console at an unguessable link, which lasts 30 days unless you revoke it first. A report names your provider and your public address, so read it before you share the link.
Two things worth knowing about the verdict. “Inconclusive” is a real answer the engine is allowed to give and it means what it says. And on Wi-Fi the radio stage reads the signal and the link rate from Windows — never the network’s name — so a weak signal is evidence like any other; on a cable that stage is skipped, which rules a radio cause out.
For ISP operators
An ISP organisation registers itself in the ISP portal (opens in a new tab), under Register your organisation. Enter your AS number if you have one; a reseller on another network’s lines registers without one and is verified by an evidence review instead. Registering grants nothing: your desk sees no subscriber until Helix has verified that you operate the network you claim. From there the sequence is deriving the validation pattern for your account numbers from real examples, and inviting your support desk. The overview is on the ISP page.
Your desk’s accounts carry capability-based roles — NOC, support, CRM, billing, read-only. A role is a set of capabilities, not a job title, and routes ask for the capability. A CRM agent can look up a service ID and read tickets and holds no quality permission at all, because consent was given for support purposes.
For the machine-to-machine integration, your network-management system is the client and always dials Helix; Helix never dials out to you. The data half of the contract is published as JSON Schema at contract.schema.json so you can generate types from it. More on the integration →
When something is wrong
The app says it cannot reach the service
Check the service is running:
Get-Service HelixCoreService. If it is running and
the app still cannot reach it, this is the pipe permissions
path — it is the one failure that only appears after a
real install, because it cannot happen when the service is run
from a terminal. The service log records the permissions
Windows actually attached to the pipe, which is the thing to
compare against.
Nothing is uploading
Open Settings → Account. If it does not say this computer’s measurements go to your account, it is not signed in: press Sign in with your browser. If it is signed in but the console’s last-seen is stale, look at Last accepted upload and at the failed attempt printed under it. An authorisation error usually means the device was removed from your account in the console: press Disconnect…, then sign in with your browser again.
If the app refuses to let you change the credential at all, this machine has the environment-variable override in force — a fleet image or a support engineer pinned it deliberately, and it is meant to survive somebody opening Settings → Account. The app will say so rather than appearing to succeed.
My ISP rejects my correct account number
The validation pattern comes from examples that ISP supplied at onboarding. If yours is a legitimate format their pattern does not cover, it is the pattern that is wrong. Tell them, or tell us — the fix is on our side, not yours.
My ISP is not in the list
Then they have not onboarded. The agent still measures everything and the Link Troubleshooter still produces a report you can export and send them by any route you like — it is designed to be readable by someone who has never heard of Helix.
A ticket email never arrived
Ticket mail is plain text carrying the reference, the service ID and a link. It is the kind of message aggressive spam filtering eats. Check the portal directly, and check the junk folder.
PDF export returns an error
PDF rendering needs a service that may not be configured on this deployment; when it is not, the API says so explicitly rather than producing a broken file. Export HTML and print to PDF from the browser.