Documenting internet outages so you can show your provider

The pattern is always the same. The connection drops for a few minutes. By the time you are through the queue, everything works again, the line gets tested and is declared fine. Next week it repeats. What is missing is not goodwill — it is a record.

What a usable record has to contain

“It goes down all the time” is not something anyone can work with. Four things make it usable:

• Time — the date and time of each individual outage, not “mostly in the evening”.
• Duration — how long it lasted. Twenty four-second outages are a different fault from two forty-minute ones, and they lead to a different investigation.
• Frequency over a period — a single outage is an incident, thirty in a fortnight are a pattern. The pattern is the argument.
• How it was measured — what was taken as evidence that the connection was gone. Without that, the number cannot be checked.

The period is the part people underestimate. Start recording when you want to complain and you have two incidents a week later. Record for three months and you have a history — which answers the first question you will be asked (“since when?”) by itself.

Why a ping log on its own falls short

The obvious do-it-yourself version is a continuous ping to one address, written to a file. Better than nothing, but it has three weaknesses that surface exactly when you cannot afford them:

• A single target proves nothing. If it stops answering, your line may be dead — or only that one server. Without telling those apart you will report outages that never happened, and lose the credibility of the rest of your list with them.
• A name problem looks like a line problem. If only name resolution fails, the connection itself is fine. Pinging a name cannot separate the two; pinging an IP address can.
• ICMP needs administrator rights on Windows and is discarded outright by some networks. An ordinary TCP connection needs neither.

Then there is the mundane part: a log that only runs while a window is open has a gap exactly where the machine was restarted — and a gap in the record is worse in a conversation than no record at all, because it has to be explained.

Keeping the history automatically

That is what UptimeLogger is built for. It runs in the background, checks the connection continuously and writes down when it was gone and for how long.

• No ICMP pings, but ordinary TCP connections to several servers from a configurable list — public DNS resolvers, addressed by their IP address. That settles the first two weaknesses above: one unreachable server is not an outage, and a broken name lookup is not mistaken for a broken line.
• A dashboard with the figures for any period you pick: number of outages, time offline, longest outage, availability.
• A year of history as a calendar heatmap — the pattern a text file would only give up after some work.
• CSV export for your own analysis and a PDF report summarising a chosen period. The report is made for exactly this conversation.

Free, no account, no telemetry. Everything stays in a local database on your own machine. Installation for Windows and macOS.

What a record like this does not do

So that the figures hold up when you use them, the other half belongs here too:

• It measures from your machine. An outage in the record means nothing was reachable from here. Whether the cause was the provider, your own router, the Wi-Fi or a cable it does not say. Claim otherwise and the first follow-up question undoes you — leaving you worse off than with no list at all.
• It measures reachability, not speed. A line that stays up but is too slow is a different matter with different evidence.
• It is not legal advice. What a provider owes, and what a record is worth in a dispute, is deliberately not stated here.

What it does do is still the part that matters: it turns “all the time” into a number, a period and a list of timestamps. Those can be discussed.

If it helped

UptimeLogger is free and stays free. If it saved you an argument with your provider, you can buy me a coffee.