ISP Evidence Report Builder

Turn saved connection tests into something a provider cannot close as anecdote.

What you paste

Parsed in your browser — never uploaded

Your saved runs, one after another with a blank line between them

How this reads your output

Paste your saved runs one after another with a blank line between them. Each is parsed separately and flagged for loss, jitter or latency in that order — the order in which those actually ruin a connection — and the whole set is summarised into text you can attach to a ticket. The judgement the tool adds is whether you have enough. One or two runs is an incident, and a provider closes tickets built on incidents by pointing at a busy moment or a wireless problem. Three or more across different times is a pattern they can check against their own monitoring, and that is what gets a ticket escalated rather than closed.

What the results mean

Runs showing a problem: How many of your runs crossed a threshold. A consistent problem across runs is what makes a claim testable.
Not yet a pattern: Fewer than three runs. The tool says so rather than producing an official-looking document that falls apart on first reading.
Loss not derivable: No run included its summary line. Packet loss cannot be inferred from reply lines, since a dropped packet leaves nothing behind.
Jitter: Variation between consecutive packets — the measurement that ruins calls, and the one a provider is least likely to have looked at.

Common problems and fixes

My runs were not recognised: Paste the whole output including the per-packet reply lines, not just the summary. Jitter needs the individual packets and cannot be derived from an average.
The provider says the line tests fine: Their test is of the line at that moment, and an intermittent problem will not be in it. Runs taken while the problem is happening, with times noted, are the counter-argument.
They blamed my wireless: Which is why the runs that matter are taken over a cable. Say in the ticket that you did, and it removes the first thing they will suggest.

Frequently asked questions

How do I prove to my ISP that my connection is bad?

With repeated measurements rather than a description. Take runs at the times the problem occurs, over several days, from a machine on a cable with nothing else running, and keep them all. A ticket saying "the internet keeps dropping" gets closed; one saying "packet loss between 8 and 11pm on five consecutive evenings, 12% average, runs attached" gets an engineer. This builds the second from the runs you have.

How many tests do I need?

At least three, and ideally across different days at the times the problem happens. Below that a provider can attribute anything to a single busy moment. What makes the set persuasive is not the number but the pattern — the same problem at the same time, with your own network ruled out.

Will they accept measurements from my own computer?

As your account of what happened, which is what a ticket is. They will not treat it as proof, and they do not need to: it is enough to make the claim specific and testable against their monitoring, which is the whole purpose. Runs that include your wireless network are the easiest to dismiss, so take them over a cable.

Put this on your own site

Free to embed, no attribution required beyond the source link the frame carries itself. It runs entirely in your visitor's browser, sets no cookies and loads no third-party script.

Embed code

<iframe src="https://runthetests.com/embed/isp-evidence-report/" width="100%" height="720" style="border:1px solid #e5e5e5;border-radius:8px" title="ISP Evidence Report Builder" loading="lazy"></iframe>

Preview it at https://runthetests.com/embed/isp-evidence-report/. Embedded pages are marked noindex, so yours stays the canonical copy — not this one.