Corrections and disputes

If a record about your endpoint is wrong, we want to know. This page says exactly what we will do about it, including the part we will not do.

How to contest a record

Write to [email protected]. It helps to include:

You do not need to prove control of the domain to report a suspected error. Proving control matters for claiming a record, which is a different thing; anyone may point out that a recorded observation looks wrong.

A published snapshot is never rewritten

Corrections land in the next snapshot. We do not edit a published one, and this is the single most important sentence on this page.

The reason is not procedural tidiness. Each snapshot commits to its records through a root that is published at the time it is made, and every later snapshot names its predecessor's root. Editing a published snapshot would break that sequence — and a record that can be edited after the fact proves nothing about what was true before the edit. An archive you can quietly change is an opinion with timestamps on it.

So the archive only ever grows. A correction is visible as a correction: the earlier observation stays where it is, the later snapshot carries the corrected one, and the difference between them is itself part of the record.

A worked example, and it is ours

In the second published snapshot, two operators running a large number of subdomains were recorded as rate-limited. That was us. Our own requests to those operators produced the throttling that we then wrote down as an observation about them.

The affected rows are a measurement artifact, they are disclosed as such on the methodology page, and the behaviour that caused it was changed so that the same class of error is structurally harder to repeat. What did not happen is the thing this page is about: the second snapshot was not rewritten to make the mistake disappear. It is still there, still saying what it said, with the correction carried forward.

This is the standard we are offering to be held to, and it is also the standard you can expect if the error is ours and concerns you.

A second one, and nobody asked us for it

On 2026-08-15 we recorded four endpoints in a class that reads as a client error on their side. They were working. They refused a handshake from our probe because our probe opens with an older revision of the protocol than they support — the current revision removed that handshake, and their refusal was correct behaviour.

No operator raised this with us. We found it by measuring our own record against the current protocol specification, and the affected rows stay exactly where they are — the earlier observations are not edited, the probe was changed so it can read what it was previously discarding, and the difference is disclosed on the methodology page with the date it took effect.

If you operate one of these four endpoints: nothing is required of you, and no claim or contact was needed for the correction to happen.

Where an observation was made from

A record can also be shaped by the network a probe came from, not by the server. The published snapshots span 2 vantages — residential-local, hetzner-nbg1 — so rows either side of that change are not comparable on this point. That is why each snapshot carries a vantage, shown beside it on the verification page and explained on the methodology page. It is not a correction and nothing about it is retroactive — it is a property of how an observation was taken, disclosed so two rows are never silently compared across a difference we already know about.

What a correction cannot do

It cannot remove an observation from a snapshot that has already been published, for the reason above. If what you want is not to appear on this site going forward, delisting is the page for that — and it is honest about its own limits for the same reason this one is.

The published list of snapshots is current as of 2026-08-20 and is shown on the verification page, where each entry can be checked at its source.