How to document internet outages before contacting your ISP

An ISP support conversation is easier when you can describe a pattern instead of a feeling.

“The internet is unreliable” is real, but it is difficult for another person to act on. A useful record answers a few concrete questions.

Keep timestamps and duration

For each meaningful outage or unstable period, record:

• when it started;
• when it ended;
• how long it lasted;
• whether service recovered on its own;
• whether the same problem happened again.

This establishes frequency and duration without requiring packet captures or advanced network tools.

Keep reliability evidence, not only throughput

A speed test can be useful, especially when the complaint is low throughput. But for intermittent failures, also keep:

• availability or uptime history;
• incident count;
• latency and jitter behavior;
• failed lightweight checks;
• the connection condition around notable incidents.

This helps show why a connection can be fast during a test but unreliable over time.

Separate local problems from provider problems

Before blaming the ISP, try to establish whether the problem is on the local side.

If Wi-Fi looks weak or the Mac cannot reach the local gateway, the evidence points inward. If the local path is healthy but direct internet or HTTPS reachability fails, the case for a wider provider/internet problem becomes stronger.

Use the simple Wi-Fi → Router → Website lookup → Internet model.

You do not need to prove the provider caused the issue. You only need enough evidence to show where the failure appears to begin.

Look for recurrence

A support case becomes more compelling when the same symptom repeats.

Useful patterns include:

• several outages over multiple days;
• degradation around the same time of day;
• repeated supported diagnoses in the same cause category;
• a clear reliability decline compared with an earlier period.

Onlink’s longer Pro history and What Onlink noticed feature are designed to summarize these patterns without turning the app into a packet-analysis suite.

Share privacy-safe summaries

Avoid sending more network identity information than support actually needs.

Onlink’s Copy Summary, Copy Evidence, and PDF reporting are designed to omit private network identifiers by default. Automatic incident forensics do not persist Wi-Fi SSID, public IP, local IP, or gateway address.

Provider name can be included only when the optional public network identity lookup is enabled.

This keeps the report focused on behavior rather than exposing unnecessary local details.

A good support summary is short

A useful summary might say:

• reliability has degraded over the last week;
• four outages were recorded;
• the longest lasted several minutes;
• local Wi-Fi and router checks were healthy during the clearest incident;
• internet reachability failed;
• two incidents had moderate or strong evidence pointing toward the wider internet path.

That gives support something concrete to investigate.

Export after enough history exists

Do not expect one afternoon of monitoring to prove a long-term pattern. Reliability conclusions should reflect the amount of measured history available.

Onlink can show Collecting data or Limited data when coverage is insufficient instead of pretending the evidence is stronger than it is.

That same principle is explained in How to read an Internet Reliability Score.

The goal of an ISP report is not to win an argument. It is to replace vague symptoms with a timeline that another person can verify and act on.