How to read an Internet Reliability Score

A single reliability score is useful only if you know what it represents.

Onlink’s Internet Reliability Score runs from 0 to 100 and is designed to answer one question: how dependable has this connection been over the measured period?

It is not a speed score.

Five parts contribute to the score

The model combines:

1. Availability — how consistently the connection was reachable.
2. Incident stability — the effect of recorded outages and degraded periods.
3. Latency — whether delay stayed within a healthy range.
4. Jitter — whether delay remained consistent.
5. Failed lightweight checks — how often background connection checks failed.

Manual speed-test throughput is deliberately excluded.

That separation matters because a fast speed test does not prove reliability.

Missing data should not become a perfect score

Sparse history is one of the easiest ways to make a health score misleading.

If a Mac has only been observed briefly, there may not be enough evidence to say the connection deserves 100 — or 40.

Onlink uses coverage states such as Collecting data and Limited data when history is incomplete. Longer periods require enough measured evidence before stronger comparisons are shown.

The point is to expose uncertainty instead of turning “we do not know yet” into “everything is perfect.”

An outage should not be punished twice

During an outage, latency or jitter may be unavailable because the remote path is not responding.

A scoring system can easily make that failure count once as an outage and again as missing latency data.

Onlink’s model avoids adding an extra latency or jitter penalty simply because those measurements disappeared during an outage. Availability and incident evidence already describe the failure.

The score is a summary, not a diagnosis

A low score tells you reliability was poor. It does not tell you why.

For cause, inspect incidents and the connection path. Evidence may point toward Wi-Fi, the router/local network, DNS, ISP/internet, a captive portal, or loss of the active interface.

This connection-path guide explains how those categories differ.

Look at the components

Two connections can have the same overall score for different reasons.

One might have excellent uptime but consistently poor latency. Another might be fast most of the time but suffer several short outages.

The components tell you what pulled the result down.

That is more useful than treating the headline number as a grade with no explanation.

Compare periods only when both are credible

A week-over-week or month-over-month comparison sounds useful, but only if both periods contain enough measured history.

Onlink can compare equivalent periods when coverage is sufficient. Otherwise it should stay quiet rather than presenting a precise trend from weak evidence.

Longer-term What Onlink noticed insights use the same principle when looking for recurring patterns.

Use the score as an entry point

A practical workflow is:

• glance at Reliability Today;
• inspect which component looks weak;
• open incidents that line up with the decline;
• check evidence strength and likely cause;
• use longer history to see whether the problem repeats;
• create a privacy-safe report if you need to contact support.

For that last step, see How to document outages before contacting your ISP.

A good reliability score compresses a complicated history. It should never erase that history.