What happens when Onlink detects an internet incident

Onlink’s background monitor is designed to notice reliability problems without behaving like a permanent stress test.

When the health model detects a meaningful incident, v1.2 can preserve more than a timestamp.

First: the incident is recorded

Internet Health can identify conditions such as an outage, unstable connection, severe latency, or a captive-portal state.

The base incident keeps facts such as start time, end time when known, worst observed condition, failure count, and worst latency when available.

That record remains useful even if richer diagnostic evidence cannot be captured.

Then: lightweight automatic evidence can be collected

During the incident, Onlink can inspect the parts of the connection path relevant to classification:

• Wi-Fi state when available;
• local gateway reachability;
• DNS resolution;
• DNS-independent IPv4 reachability;
• IPv6 reachability;
• HTTPS reachability.

This uses the same deterministic cause model as manual Diagnose, so the automatic and manual paths do not invent separate definitions of “DNS problem” or “ISP problem.”

It does not run a full speed test

Automatic diagnosis intentionally avoids Cloudflare and M-Lab throughput tests.

It also avoids the manual Diagnose loaded-responsiveness transfer.

Those are explicit, user-started actions because they can move substantially more data and alter network load.

For the reasoning behind that choice, read How much data should an internet health monitor use?.

Evidence is attached to the incident

When available, Incident Detail can present:

• what happened;
• a before/during/after timeline;
• the likely cause;
• evidence strength;
• a simple path such as Wi-Fi → Router → Website lookup → Internet;
• technical details that can stay collapsed until needed.

Supported likely-cause categories include Wi-Fi, router/local network, DNS, ISP/internet, captive portal, loss of the network interface, and unclear.

Recovery matters too

A failure tells you where the path looked broken. Recovery evidence helps confirm that the same path returned.

Onlink can add a recovery snapshot after the connection is actually online again.

Short flaps merged into the same incident are not meant to trigger repeated full automatic capture for the same event.

Privacy is part of the incident model

Automatic forensics deliberately avoid persisting the Wi-Fi SSID, public IP address, local IP address, and gateway address.

Those values may be inspected transiently when needed for diagnosis, but the stored incident evidence focuses on state and outcome rather than unnecessary identifiers.

Copy Evidence and reports follow the same privacy-first direction.

Old incidents stay honest

Incidents recorded before v1.2 did not have automatic forensics.

Onlink keeps them readable, but displays Cause unavailable instead of trying to infer what happened from information that was never captured.

That rule is important: historical data should not become more certain just because the software became more capable later.

For why this matters most with short-lived failures, see Why intermittent outages are hard to diagnose.

The automatic system is intentionally modest. Its job is to preserve the right lightweight evidence while the problem is happening, then let you inspect it after the network has recovered.