Every term, in plain words.

How a measurement is made

Almost everything below is built from one small act, repeated constantly.

Packet

The unit everything on the internet travels in. A message is chopped into packets, each finds its own way, and they are reassembled at the far end. Losing one is normal; losing many in a row is not.

Probe

One tiny packet Helix sends to a known address, asking only “are you there?”. The reply time is the measurement. The agent sends these continuously, whether or not the app window is open, which is why the evening your call kept breaking is still on the record next morning.

Round trip

Out and back. Every delay figure here is a round trip, not a one-way journey — there is no way to measure one way without a clock at both ends that agree.

Window

One minute of probes, closed and summarised. Helix reports on closed windows rather than on the live moment, because a figure calculated from a third of a minute changes under whoever is reading it.

Delay: latency and jitter

Latency

How long a round trip takes, in milliseconds (ms). It is the number that decides whether a call feels natural or like a walkie-talkie. Distance sets a floor no provider can beat: a packet cannot outrun light, so a server on another continent is honestly slower than one down the road.

Reading it: what matters is not the absolute figure but whether it is normal for your line. Helix grades latency against your own baseline for exactly this reason. A satellite connection at 600 ms is behaving correctly; a fibre line that normally sits at 8 ms and is now at 90 ms is not.

Median, p50, p95 and the “slow tail”

Averages hide the problem. If nineteen packets take 10 ms and one takes 400 ms, the average looks fine and your call still glitched.

• Median (p50) — the middle value. Half your packets were faster, half slower. This is the “typical” experience.
• p95 — the value 95% of packets came in under. Helix labels this the slow tail: roughly one packet in twenty is at least this slow. It is the figure that predicts whether a video call stutters, because the worst packets are the ones you notice.

Reading it: a median close to the slow tail means a steady line. A small median with a slow tail many times larger means an inconsistent one — and inconsistency is what breaks calls, not the average.

Jitter

How much the delay varies from packet to packet, in milliseconds. Measured the standard way (RFC 3550), the same definition telephony equipment uses.

Reading it: voice and video hide jitter with a buffer, which works until the variation exceeds it — then you get robotic audio or a frozen frame. A line can have excellent latency and still be unusable for calls if jitter is high, which is why Helix shows both.

Loss: counts, runs and the floor

Why counts and not percentages

Helix reports “3 lost of 240” rather than “1.25%”, everywhere, on purpose. A percentage cannot be checked or re-added: 1% could be one packet out of a hundred or a thousand out of a hundred thousand, and those are different conversations with a support desk. The count travels with every figure so anyone can verify the arithmetic.

The 300-probe floor

Below 300 probes, Helix will not quote a loss rate at all — it shows the counts and marks the sample thin.

Why it matters to you: with 40 probes, one unlucky packet is “2.5% packet loss”, which sounds alarming and means nothing. A support desk can dismiss it in one sentence, and would be right to. Waiting for a real sample is what makes the number survive that conversation.

Loss run

The longest unbroken stretch of lost packets. Twenty packets lost one at a time across an hour is background noise the internet is designed to absorb. Twenty lost consecutively is a dropout you heard.

Reading it: this is often the most useful number on the screen. A large total with a run of 1–2 is usually fine. A small total with a run of 15 is the moment your call dropped.

Speed, and why it is not quality

Throughput (Mbps)

How much data the line can move per second — the number on your bill. It answers “how long does this download take?” and almost nothing else.

Reading it: a connection can hit its full advertised speed and still be terrible for calls, gaming and video conferencing. Speed is capacity; latency, jitter and loss are quality. Most complaints that reach an ISP as “my internet is slow” are quality problems on a line that passes every speed test.

Bufferbloat, graded A–F

What happens to your delay while the line is busy. Equipment along the path holds packets in queues rather than dropping them; when those queues are too large, a download fills them and everything else waits behind it.

Reading it: this is the single most common explanation for “my call breaks up when someone else is streaming”. Helix measures the delay added under load and grades it. An A means the line stays responsive while busy; a D or F means it does not, and no amount of extra speed will fix it — the fix is queue management on the router, which is usually a setting rather than a purchase.

The scores and grades

Every score below is computed from the figures shown beside it, so the arithmetic can be checked rather than trusted.

Responsiveness

A 0–100 summary of latency, jitter and loss from the same closed windows shown next to it. It answers “how quickly does this line answer, and how consistently?”

90 and above reads as excellent, 75 and above good, 50 and above fair, below that poor.

Mean rating, and the three activities

Helix rates the line for calls, gaming and streaming separately, because they fail differently: streaming tolerates delay but not sustained loss, while a call tolerates neither jitter nor loss but needs very little bandwidth. The mean rating is the average of those three.

85 and above is excellent, 65 and above good, 40 and above usable, below that poor.

Deliberately not included: speed. Scoring megabits needs an absolute scale — somebody deciding that 50 Mbps is “good” — and that number would be invented rather than measured. The panel says so on its own face rather than letting you assume speed is in there.

MOS

Mean Opinion Score: a 1–5 estimate of how a voice call would sound on this line right now, calculated from latency, jitter and loss using the standard telephony model (the E-model). 5 is flawless, 4 and above is what people describe as a good call, below 3 is where you start asking people to repeat themselves.

It is an estimate from measurements, not a recording of a real call.

The path: hops and who owns them

Hop

Each router your traffic passes through on the way to its destination. A typical path has somewhere between five and twenty. The first is usually your own router; the last is the far end; the ones between belong to your ISP and the networks it connects to.

Traceroute and MTR

A traceroute lists the hops. An MTR keeps measuring all of them at once, so instead of a snapshot you get loss and delay per hop over time. This is what turns “the internet is broken” into “the fourth hop, which belongs to your ISP, is dropping packets”.

Propagating loss, cosmetic loss, and the culprit

This is the most misread thing in networking, and the reason naive tools accuse the wrong party.

• Cosmetic loss — a hop shows heavy loss but every hop after it is clean. The router is simply deprioritising the replies Helix asked for; it is forwarding your real traffic perfectly. This is normal and means nothing. It is often the biggest loss figure on the screen, which is exactly why it is labelled rather than ranked.
• Propagating loss — a hop shows loss and so does everything after it. The loss is real and everything downstream inherits it.
• The culprit — only the first hop where loss starts propagating is named. Everything past it is a victim, and marking them all points at nobody.

TTL

A countdown on every packet that stops it circling forever if routing goes wrong. Traceroute works by abusing it deliberately — sending packets designed to expire at hop 1, then hop 2, and so on, so each router in turn announces itself.

ASN and AS

An Autonomous System is one organisation’s chunk of the internet, identified by a number like AS36866. It is how you tell whose equipment a hop belongs to — and therefore who to call. Helix annotates hops with the AS so a path reads as a sequence of companies, not just addresses.

Names: DNS and resolvers

Resolver

The service that turns a name you type into an address the network can route to. Usually your ISP’s, sometimes one you chose. When it is slow or wrong, every site feels broken while the connection itself is perfectly healthy — which is why this is measured separately.

Reference comparison

Helix asks your resolver and two independent ones the same questions. The comparison is the diagnosis: answers from the references and none from yours points at your resolver, not your line.

A resolver that disagrees with the references is reported neutrally, because large sites legitimately answer differently by region. A resolver that returns an address for a name that cannot exist is reported as redirecting failures — that one is a real finding.

Your kit, their network

Gateway

Your own router — the first hop. Helix measures it separately from the internet targets, and the distinction carries most of the value in the product: loss between your PC and your gateway is your side (Wi-Fi, a cable, the router itself) and no ISP can fix it. Loss beyond it is theirs.

CGNAT

Carrier-Grade NAT: many subscribers sharing one public address. Normal on mobile and on many fixed providers. It can break incoming connections — some games, some remote access — and it means your connection cannot be identified by address alone, which is why Helix asks you to confirm which line is yours rather than guessing.

Outages and attribution

What counts as an outage

Not “it felt bad”. An outage is a specific, defined condition, and Helix will not call something an outage without evidence that meets the definition. That threshold is what makes the word usable in a complaint.

Consensus

If several independent targets stop answering at once, the problem is your line or your provider. If one stops, that service is down. Helix requires agreement across targets before blaming your connection, so an outage at one popular site is not recorded as your internet failing.

Maintenance window, and the 15-minute rule

A provider can declare planned work, and faults inside that window are not attributed to them. It only counts if declared at least 15 minutes before the fault. Without that rule, a window declared afterwards is a retroactive amnesty, and the feature would quietly erase the evidence it exists to preserve. Retroactive claims are still shown — marked, so you can see one was made.

---

Still unclear on something? The methodology page gives the reasoning behind these rules, and contact reaches a person.