EchelonGraphBot: Radar scanning policy

EchelonGraph, Inc. is a security company. Radar is our free, public internet-observability feed. It measures publicly reachable web endpoints — reachability, TLS configuration, HTTP response headers — and publishes what it measured, with the time it was measured. How EchelonGraph handles personal data generally is set out in our Privacy Policy.

Radar is free and public. No account, no payment, no login and no customer relationship is required to read it, to be in it, or to dispute it. The operator of a domain we have measured has exactly the same access to the record as anyone else, and the same right to correct it.

What Radar publishes is a measurement, not a verdict about your organisation. Where Radar puts a letter grade on something — its HTTP security-header grade — that grade is attached to a single URL, in the manner of Qualys SSL Labs' per-server assessment. It is not a company-level rating. We do not aggregate endpoints into one score for a named company, and we do not sell such a score. This distinction is deliberate and we consider ourselves bound by it.

Radar's foundational rule, enforced in the prober's code and not merely stated here: Radar makes its own requests as an ordinary anonymous public client and measures its own responses. It never observes anybody else's traffic.

Radar is active. The Discovery Radars covered on our Responsible Disclosure page start from data that is already public and are described there; Radar is different in kind — it makes its own HTTP and TLS requests to the endpoints it measures — so it has this policy of its own, and nothing on that page should be read as describing it.

How a domain comes to be probed, and how long the record lasts

A probe job reaches the prober from exactly four sources. The wire contract accepts no others — a job carrying anything else is rejected before it is dispatched. (Amended 19 September 2026, #1903: this read “exactly three sources”; the re-check is the fourth.)

• • We will tell you which of the four put your domain on the list. Ask at [email protected], naming the domain.
• • Some domains are not probed, whatever the source. Our legal sign-off record excludes the comprehensively sanctioned jurisdictions, and Russia and Belarus pending advice, and we apply that as a rule about names: a host whose name ends in .ir, .kp, .sy, .cu, .ru, .su or .by, or in the internationalised top-level domain of Iran (xn--mgba3a4f16a), Syria (xn--ogbpf8fl), Russia (.рф, xn--p1ai) or Belarus (.бел, xn--90ais). Our scheduler does not select it. The prober refuses it before any request — or DNS lookup — is made for it, whether it is the host a job names or the target of a redirect, and its robots.txt fetch refuses the same hosts. And our public feed does not publish it, nor a host whose retained probes ended at one. It is a rule about the name, not a finding about where a server is: a host in one of those countries under another name is not caught by it, and a host elsewhere under one of those names is. The record also names the occupied regions of Ukraine, which have no top-level domain of their own, so this rule cannot express them. (Added 24 September 2026 (#2150): .su, the Soviet-era country code, which is administered from Moscow and answered by the same name servers as .ru. It took three more domains out of the daily selection above, which read 9,619 until that day. The rule has not always held. Our first run, on 7 September 2026, came before it existed and reached iranjib.ir and yandex.ru (#1722); until 13 September 2026 it compared the wrong part of a name and let google.com.cu through once (#1840); and until 24 September 2026 it was applied to the host a job named and not to where that host redirected us, so a probe of a host outside these domains that redirected into one was followed there — avs.io to www.aviasales.ru, for example (#2149).)
• • An on-demand request from a stranger will buy no privileges. It will be charged to the same politeness budgets and defeated by the same exclusions as any other job, so a stranger will not be able to use it to have you probed harder than the schedule would — with one bounded exception, the re-check below — or to reach a domain you have excluded. Stated in the future tense because the general on-demand route for a visitor is not built (#1257). Two on-demand callers exist. Since 13 September 2026, a domain’s own verified operator asking us to monitor it — a shorter interval for that one domain, which nobody but its operator can start, and which still meets every budget and every exclusion. And anyone asking us to re-check a host we are currently publishing an open incident about — one more probe of that host, at most one re-check an hour on top of its ordinary scheduled probe however many people ask, which still meets every budget and every exclusion, so a host you have excluded is never re-checked. That second caller is switched off today: our main platform, which takes the request, has its on-demand checks of the hosts we report on switched off, so the Re-check button on the board and on a host’s own page is drawn switched off and sends nothing. Both are described in the next bullet. The scheduler and the exclusion check are both live: the scheduler runs continuously, and the exclusion check was consulted on every one of the 2,446 jobs in the prober’s contact-log count taken on 13 September 2026.
• • How often we re-probe you, and how long we keep it. No host we do not own is probed more than once every 24 hours, unless its operator has proved they control it and asked us to check it more often, or we are publishing an open incident about it and someone has asked us to re-check it, which adds at most one re-check an hour to its ordinary probe. That is refused by the prober itself before a request is made, not merely scheduled that way. Throughout this page a stranger is a host we do not own whose operator has not asked us for anything, and the 24 hours is a stranger’s cadence. There are three exceptions, they are different in kind, and each is stated here so that you can check it. The first exception is our own hosts, and it is deliberate. When self-probing runs, we probe echelongraph.io as fast as our own per-host budget allows, because a limit that has never refused anything is a limit nobody has watched work, and everything below this line is a promise we would rather test against ourselves than against you. The exception has been in the prober since 8 September 2026; self-probing itself last ran on 9 September 2026 and does not run today — the list of our own domains the scheduler used to feed it was removed when third-party probing was armed, and our own domain has not appeared in the public feed in the last seven days. (Corrected 19 September 2026: this read “We probe echelongraph.io as fast as our own per-host budget allows” and “Live since 8 September 2026”, with nothing to say it had stopped on 9 September — which the status box above already said.) The sentence about the exception stood in the future tense for part of 8 September 2026, while the change was merged and the prober carrying it was not yet deployed; it moved to the present tense on the day that revision shipped, which is the order we said we would keep. The exception is a match against a fixed list of domains we own, on a label boundary — so a name that merely ends in ours is a stranger and gets the 24 hours. That list is shared/pkg/ourhosts, it has one entry, and adding to it is a commit that has to say why we own the host. For our own hosts the interval is not shortened: it does not apply at all, because for a host we own it is a promise to nobody.
  The second exception is yours to grant, and it shortens the interval rather than removing it. Added 13 September 2026 (#1834). The operator of a domain can prove they control it — the same mechanism the opt-out register uses, a TXT record at _echelongraph.<domain> carrying a token we issue — and ask us, on the monitor screen at echelongraph.io/radar/monitor, to check that domain continuously. A domain under that consent is checked no more than once every 30 seconds. Its operator picks a cadence from a closed set — 30 seconds, 1 minute, 5 minutes or 15 minutes — and nothing faster than 30 seconds can be chosen, so 30 seconds is the commitment and the rung is the operator’s choice. What applies today is the rung chosen, or one minute, whichever is slower: the prober claims each consented domain at the rung its operator chose, but our scheduler sends a consented check no more often than once a minute, so 5 and 15 minutes are honoured as chosen and a 30-second choice is honoured at a minute — never faster than the floor, so nothing on this page becomes false, but do not read a 30-second choice as the cadence in force until this sentence says otherwise. (Corrected 19 September 2026: this said the prober applies “one minute to every consented domain, whichever rung was chosen” and “does not yet read the chosen cadence”. The prober reads it, since a change made on 13 September (#1834); the minute is our scheduler’s, and it binds only a 30-second choice.) Consent is not ownership, and the two are never merged: a consented domain still claims a per-host slot before every probe and is refused if it is asked too soon; it still meets your robots.txt, the per-host and per-provider budgets, the backoff and the opt-out register exactly as a stranger does; and it is refused by the approved-jurisdiction exclusion exactly as a stranger is. What changes is one interval and nothing else. The consent is matched on the exact name, so proving example.com monitors example.com and not www.example.com; and a domain that is also in our registry keeps its once-a-day scheduled visit as well, counted against the stranger budget as before.
  How much traffic that can ever be, and whose budget it comes from. At most 25 domains can be under consented monitoring at once, across everyone; the twenty-sixth is refused with a reason that names the cap, never queued. So the most consented checks can produce is 25 domains, twice a minute, all day — 72,000 requests a day — counted where each job is published and refused above that. That ceiling is separate from the daily ceiling our sign-off record sets for hosts that did not ask us to contact them: consented checks are counted on their own and never draw on the stranger budget, so nobody can use a monitor to spend the ceiling that protects you, and the stranger ceiling never describes a population that asked.
  How it stops, and how you can see whether a domain is under it. A monitor runs only while someone is watching it: the screen renews a lease every 30 seconds, a lease that goes 120 seconds without renewal lapses, and our scheduler consults the register every 15 seconds — so close the last screen and nothing further is scheduled within about two and a quarter minutes, with no account and no action on your part. The proof itself is trusted for 7 days and then must be renewed by the same DNS check; remove the record and it cannot be renewed. To end it at once, remove the record and POST https://app.echelongraph.io/api/v1/public/radar/monitor/stop with the domain; that goes through only once the record is confirmed gone, so nothing a stranger can do stops a monitor whose owner is still publishing consent for it. To see whether any domain is under consented monitoring, and at the cadence its operator chose, ask GET https://app.echelongraph.io/api/v1/public/radar/monitor/<domain>: it needs no account, answers 404 for a domain nobody has asked about, and for one that has says whether it is pending, active, unwatched, expired or stopped. If our checks are arriving faster than a stranger’s once a day, that answer is not active, and we are not publishing an open incident about your host (the third exception, next), that is a defect on our side and we want the report at [email protected].
  The third exception is anyone’s to ask for, and only about a host we are publishing an incident about. Added 19 September 2026 (#1903), to ship with the code rather than after it. Re-checks are switched off today: our main platform, which takes the request, has its on-demand checks of the hosts we report on switched off, so the Re-check button on the board and on a host’s own page is drawn switched off and sends nothing. What follows is what a re-check is when they run. When re-checks run, a host we are currently publishing an incident about may be re-checked by anyone at most once per hour, so that a resolved problem clears from our list faster — in addition to its ordinary scheduled probe, not instead of it. “Publishing an incident about” means an open record on echelongraph.io/radar: the host answered our probe with a server error on consecutive probes, and no later probe has answered without one. A re-check would be one more probe of that host, sent when someone pressed Re-check on the record — on the board or on the host’s own page — and it would need no account and no proof of ownership. The incident closes only because that probe, or a later one, got an answer that was not a server error; nobody can close an incident by asking. Three bounds keep this from being a way to point our prober at somebody. The eligible set is our own published list of open incidents and nothing else: a request about any other host is refused before anything is sent. The hour is per host, not per person asking: once anyone has asked, nobody can ask again about that host for an hour, however many windows they open, because the limit is there to protect the host — and it is enforced twice, by our backend before it asks for the probe and by the prober’s own re-check claim, a one-hour slot of its own kept apart from the ordinary one, so a second re-check inside the hour is refused before a request is made even if the first limit were wrong. Our backend also refuses a re-check within an hour of any probe of the host, the ordinary one included — it reads the prober’s own claim on the host, which is taken before the request is sent, as well as the newest probe we have recorded — so a re-check never lands minutes after the ordinary probe; the other order — a re-check, then the host’s ordinary scheduled probe within the hour — can happen, as often as that ordinary probe does. And it bypasses nothing: it adds at most one probe an hour (like any probe, a robots.txt fetch, the GET and its redirects, so more than one request) and changes nothing else — the ordinary claim is left as it was — so a re-check still meets your robots.txt, the per-host and per-provider budgets, the backoff and the opt-out register exactly as a stranger’s probe does, and a host on the opt-out register is never re-checked — which is also how to make sure nobody can ask. So the most re-checks can add, on top of the ordinary scheduled probe, is one probe an hour to a host we are already publishing an incident about, for as long as that incident stays open.
  An individual observation is kept for 90 days; the hourly and daily summaries derived from it are kept for 13 months. Both are deletions the store performs, not a policy someone has to remember to apply. The summaries still name your domain — they aggregate over time, not over subjects, so they are not anonymous and we do not call them that. Radar ran scheduled probes every day from 9 September 2026 until its prober was stopped on 8 October 2026, and again since 17 October 2026, so these are the bounds actually in force; the retention periods kept running while it was stopped. (Amended 8 October 2026: this sentence read “Radar is running scheduled probes today, so these are the bounds actually in force”.) And the resting interval for a stranger is a deliberately conservative one — raising it is a change to this page first and the system second. Where each of these lives, so you need not take our word: the interval is claimed per host before a probe by radar-prober/internal/reprobe against the value in shared/pkg/politeness, or against the consented value in shared/pkg/radar for a domain whose operator asked, or, for a re-check of a host we are publishing an incident about, in a separate one-hour claim (radar-prober/internal/recheck) against the re-check interval in that same package; the cap, the ceiling, the floor and the lease are constants in that same package, and the register is core-backend/internal/radarmonitor; both retention periods are TTL clauses our analytics store applies, rendered from shared/pkg/chschema. A test in our code fails if any of those figures stops matching the code that enforces it, the re-check’s hour included — when our tests are run. Nothing runs them automatically today: no automated build runs them on each change and our deploy does not run them, so a disagreement is caught when the suite is run, not on every build. (Corrected 19 September 2026: this said “A test fails our build”, which describes a build that has not been running.)
• • How hard we push, per host and per provider. To any one host: one request every 5 seconds sustained, one connection open at a time, and a short burst of 4. To any one hosting provider — an autonomous system, not one of its customers: 5 requests per second sustained, 10 connections, burst 20. After a 403, a 429, a 451 or a 5xx we wait 1 minute, double that on each consecutive failure, and cap the wait at 30 days.
  Both halves of that sentence changed on 9 September 2026, and the old version was worse than it looked. It read “after a 429 or a 5xx… capped at 24 hours”. A 403 — which is what most of you actually return to a bot you do not recognise, and which 820 of you returned to us in one day against six 429s — was not on the list at all. Worse, it was treated as a successful answer, so it CLEARED whatever delay earlier refusals had earned: one 403 in the middle of a run of 429s collapsed the next wait from sixteen minutes back to one.
  And the cap could not bind. It was 24 hours, which is also the soonest our schedule re-asks any host we do not own whose operator has not asked us for more, so the longest delay the backoff could impose was exactly the delay you already had. (Amended 19 September 2026, #1903: this read “the soonest we ever re-ask”; a re-check of a host we are publishing an incident about, the third exception above, can now reach such a host sooner.) Our own counters say it plainly: across 20,170 jobs the backoff refused one. At 30 days it can. A host that keeps refusing gets roughly a dozen daily attempts, at a stranger’s cadence — enough that a transient rule or an outage is not read as a permanent no — and then the interval grows to 34 hours, 68 hours, 5.7 days, 11 days, 23 days, and a month from the seventeenth refusal.
  Your Retry-After is still capped at 24 hours and that did not move. The 30 days is how far OUR OWN judgement escalates after repeated refusals; the 24 hours is how long a SINGLE header from you may park us, because a host answering Retry-After: 999999999 has said something broken and we will not treat it as a permanent opt-out nobody reviewed. Two different numbers doing two different jobs.
  Some of these are borrowed and the rest are ours, and the difference matters if you are checking us. The sustained per-host rate and the one-connection cap match the two reference crawlers: Apache Nutch ships fetcher.server.delay at 5.0 seconds with one thread per queue, and Heritrix waits 5× the previous fetch, floored at 3 seconds. We sit at the slower end of that pair. The burst of 4 is our own choice, and neither crawler permits back-to-back requests at all. We allow it because one observation is a robots.txt fetch, the request itself, and its redirect chain — http → https → www is the common shape — so four lets a single visit finish without a five-second pause between its own steps. It is four steps of one visit, not four visits; anything longer runs at the sustained rate. The per-provider numbers have no precedent to cite — no reference crawler publishes a per-provider budget — so they are our judgement, and they are deliberately lower than scheduled probing will need, so turning it on means raising them. We would like to tell you that raising them requires changing a number on this page. It does not. An operator can raise them through our admin API at any time, up to a hard ceiling in the code, and this page would not change — which is the gap we describe next.
  Where each of these lives, so you need not take our word: all eight are constants in shared/pkg/politeness, enforced by radar-prober/internal/probelimit and radar-prober/internal/backoff before a request is made. A test in our code fails if any of these figures stops matching the code that enforces it — when it is run, which, as said above, is not yet on every build. (Corrected 19 September 2026: this said “A test fails our build”.)
  An operator can change all eight at runtime, and all eight are checked — but only while a prober is running, and from 7 September 2026 until it was stopped on 8 October 2026 one was kept running, as one has been again since 17 October 2026. When a prober reads a policy that makes any figure here weaker — a higher rate, a bigger burst, more connections, or a shorter backoff — it says so in its own logs, naming the figure, its new value and the published one, and an alert fires. It repeats that every five minutes for as long as the figure stays weaker.
  The honest limit, and what it was until 8 October 2026: from 7 September 2026 this service kept one instance alive continuously, so a change to any figure here was read on the loader’s own interval — it re-reads the policy every 30 seconds — rather than whenever something next happened to run. That is the bound, and it is not “instantly”: one loader interval after the write, on a running instance. Two things still limit it. It is one instance, and a deploy replaces it; a change made in that gap is read when the new instance boots, not before. And a kept-alive instance is a setting we asked for, not a measurement we have made: we measured the old arrangement and have not yet measured this one, so this paragraph carries no uptime figure until we have.
  Corrected 7 September 2026 — this paragraph previously read: “The honest limit, measured rather than estimated: this service has no minimum instance count, so it starts, works and is reclaimed. Over the 44 hours to 7 September 2026 it was running 11% of the time, with a median gap of about an hour between instances and a longest gap of 14 hours. A change made while nothing is running is not noticed until something runs. We are not going to describe that as ‘within minutes’. Keeping one instance alive continuously is what fixes it, and that arrives when scheduled probing does.” Every number in it was true of the 44 hours it measured, and it is kept here because it was. Its last sentence was a promise — that a kept-alive instance arrives when scheduled probing does — and both arrived on 7 September 2026, the warm instance first and probing a few hours after it — and probing was paused again the same day, while the instance stayed. We brought the instance forward on its own merits, because the loader and the alert above are worth nothing on a service that is asleep, and for a few hours that was the only thing that had changed.
  What we do not alert on, deliberately: a change that makes us more conservative than we published. That leaves everything on this page true, and a rule that paged on it would be switched off within a week — taking the useful half with it. The test above is the other half: it catches this page and the code disagreeing when it is run — which, as said above, is not yet automatically on every change. (Corrected 19 September 2026: this said it catches the disagreement “at the moment someone edits either”.)
• • If you block us and never contact us, nothing is removed. Tier 1 stops future probes reaching you; observations already published stay until they age out or are superseded. Removal of what is already published is Tier 2, it is free, and it does not require a reason.

One Radar probe is a single well-formed HTTP GET of the origin's root path, over http or https. No POST, no crafted paths, no parameter fuzzing, and no follow-up request probing what the first response revealed.

Because “how many times did you hit me” is the question you are most likely to be asking, here is the complete set of requests one probe can make of you, so that a count in your access log reconciles against this page:

• • The GET itself. One.
• • Redirects. Where your server redirects us, we follow the chain up to a cap of 10 hops. Each hop is a further GET, so a probe that is redirected repeatedly is up to eleven GETs of your pages — and more requests than that in total, because each hop’s robots.txt is fetched before that hop’s GET, and a robots.txt fetch will itself follow up to five redirects. We do not follow a redirect to a host under a top-level domain we exclude by jurisdiction (the list is under How a domain comes to be probed): since 24 September 2026 that hop is refused before any request or DNS lookup is made for it, and the probe ends there with no measurement kept. A robots.txt fetch refuses the same hops, and a host whose robots.txt redirects to one is treated as having refused us, so it is not probed. We are not going to put a single number on the worst case, because the honest one depends on how your redirects are arranged. Since 24 September 2026 our operational log names the host of every request a probe sends, in order, so we can now tell you which hosts a redirected probe reached — but it records host names only, never a path, and one time per log line rather than one per request, so it still cannot give you each request’s exact time or URL (#1725). (Corrected 24 September 2026: this said “we do not record the hops”. And until that day the excluded top-level domains were applied to the host a job named and not to its redirects, so a redirect into one was followed.) Corrected 8 September 2026: this read “up to eleven requests”, counting only the GETs — the same undercount this page corrected in its status box and left standing here.
• • robots.txt. The robots check is on the probe path (see Rate and politeness), so each host also receives one GET /robots.txt, cached rather than re-fetched for every probe. A host whose robots.txt we cannot read gets nothing further, because we treat an unreadable file as a refusal. Whether it received the fetch at all depends on why we could not read it: nine of the 40 jobs on 7 September 2026 ended at this step, and in all nine the connection failed before any HTTP request was sent, so those nine may have no record of us at all. Corrected 8 September 2026: this read “receives that request and nothing else”, which was the same false claim the status box above had already retracted, left standing here because that fix corrected one passage and announced the claim fixed.
• • One job, starting at http. Every job we schedule — the daily one, a consented check and a re-check alike — starts at http:// on port 80 and follows your redirect, so a host that sends http to https is reached on both ports within that one probe, and the https hop is one of the redirects counted above rather than a second job. A host with port 80 closed is not tried on 443 by that probe. (Corrected 19 September 2026: this said a domain reachable on both ports was two jobs, one per scheme, each carrying the counts above. Our scheduler has never made a job per scheme.)

That is the complete set. We make no request of you that is not in that list.

The request

Bounds on a single probe: whole-probe timeout 20 s (hard ceiling 60 s); TCP connect timeout 5 s; TLS handshake timeout 5 s; redirect hop cap 10; one connection per hop, not reused.

Two limits on the response body — and the larger one costs you bandwidth

The second figure is what one probe can cost you in bandwidth. A response body larger than 64 KiB is drained up to 4 MiB by default. We publish that number rather than the flattering one: an operator who meters egress will see it, and would be right to distrust everything else on this page if it were not here.

What we read, and what we keep

We read the response status line, the response headers, the TLS handshake and certificate chain, the timings of each stage, the redirect chain, and a bounded prefix of the response body. We keep less than we read, by design:

• • The response body is not stored. It is read in memory so that the header and mixed-content detectors can run, and it is then discarded. The published record has no field that could carry it.
• • The redirect chain is not stored with the measurement. The record we keep has only the number of hops and the final URL; we do not publish a list of a third party's URLs. Our operational log does keep the host names. Since 24 September 2026 the log line for each probe names the host of every request it sent, origin first, and the host it ended at; the line for each robots.txt fetch does the same for that fetch’s redirects; and when the prober refuses one of a probe’s redirects because of where it points, the line that records the refusal names that host, although nothing was sent to it. Host names only — never a path or a query string. We keep them so that a request to a host under a top-level domain we exclude by jurisdiction can be detected, and so that “was this traffic yours?” can be answered for a host we reached through someone else’s redirect. That log is kept for 30 days and is not published. (Corrected 24 September 2026: this said only “The redirect chain is not stored”, which stopped being the whole answer that day.)
• • Certificate problems are recorded, not treated as failures. We complete the handshake with verification switched off and verify the chain ourselves afterwards, against public trust anchors, so that an expired or mismatched certificate is reported as a measurement rather than as a probe that failed.

Switching verification off in the handshake changes nothing about your configuration and nothing about your security. It does create one exposure, and it is an exposure to the accuracy of what we publish about you: a party able to intercept the connection between our vantage point and your server could present a certificate that is not yours, which we would accept, grade and attribute to your domain by name on the public feed. Two things limit it, and neither is complete. We never act on the certificate: no credential is sent over that connection and nothing is trusted on the strength of it. And where our own trust store is not usable, an adverse chain verdict is withheld rather than published, so our defect cannot be printed as your defect. What does not exist yet is corroboration of a certificate from a second vantage point before publication Not yet; until it does, Right of reply and correction is how such a record gets corrected.

Not a probe: what a registry sees from us

One other kind of request carries our name, and it is not addressed to the host a Radar page is about. For a domain’s Radar page, our backend asks the domain’s registry — Verisign for a .com, DENIC for a .de — for the registration record it already publishes over RDAP (the last row of What we never do). The lookup is addressed to the registry, never to the domain’s own servers. To learn which registry that is, it fetches IANA’s bootstrap file, https://data.iana.org/rdap/dns.json, which each instance of our backend fetches when it first needs it and then keeps for a day; after a failed fetch it does not try again for five minutes. If you run a registry’s RDAP service, or IANA’s, this is what reaches you when your server chooses HTTP/1.1:

When it chooses HTTP/2, the same fields arrive as HTTP/2 headers, in lower case, and without the Connection line, a header HTTP/2 does not carry.

(Added 26 September 2026, #2288. Until this date the lookup did not keep that budget: up to four of its requests at a time went to one registry, each as soon as the one before it was answered, over connections kept open between requests; a 429, 502, 503 or 504 was retried after one second; and a redirect hop could carry a Referer.)

(Amended 26 September 2026, #2288: when the lookup was first held to that budget, earlier the same day, it spoke HTTP/1.1 only, offered nothing else in the TLS handshake and sent Connection: close on every request, and a lookup that ended in an error was not due again for seven days. A registry that serves only HTTP/2 — TWNIC’s, for .tw, answers HTTP/1.1 with 426 Upgrade Required (measured that day) — could not be read that way, and each such lookup was recorded as an error. Since this amendment the lookup offers HTTP/2 as well, a refusal of our protocol records nothing, and a domain whose lookup ended in an error is asked about again after a day.)

Anyone can put our name in a User-Agent string. That is precisely why we do not ask you to take the User-Agent as proof, and why every request also carries a signed receipt. Traffic claiming to be EchelonGraphBot is not necessarily ours, and if you are seeing abusive traffic under our name we want to know ([email protected]) — it is our reputation being spent.

Three channels are described below. The first exists and is forgeable. The second exists and is not forgeable, but it depends on our signing key being mounted and on your logs recording full request headers, and it can only be checked by asking us. The third exists in part: one address — the one reserved for our scanning — is published and you can act on it today, and what is missing from it is the machine-readable ranges file and reverse DNS that names us. Corrected 8 September 2026: this read “The third does not exist yet”, which this page contradicted 85 lines further down and which steered you away from a check you can make without us. Where you have no receipt to check, we offer a direct answer instead. Email [email protected] with the source IP and the timestamp, and we will tell you from our own egress records whether that traffic was ours.

EchelonGraphBot/1.0 (+https://echelongraph.io/bot) follows the convention RFC 9309 §2.2.1 states for crawlers: “The product token SHOULD be a substring of the identification string that the crawler sends … The identification string SHOULD describe the purpose of the crawler.” The +URL resolves to this page. From: [email protected] is a mailbox a human reads.

This channel is a courtesy, not evidence. It is trivially spoofable. Use it to find us in your logs, not to conclude anything.

Every Radar request carries a signed receipt, as two headers with one value. X-EchelonGraph-Verify is a clickable URL, https://echelongraph.io/verify-scan?token=v1.<payload>.<signature>, and X-EchelonGraph-Receipt is the bare token. The token is an HMAC-SHA256 signature, keyed by a secret that never leaves our servers, over the host the request was addressed to, the port, the name EchelonGraphBot and the time of issue. It signs the hostname, not the address it resolved to, because the headers are written before we dial; and each redirect hop is issued its own receipt for its own host, so a host we reach through your redirect holds a receipt naming itself, not you. A third party cannot mint one, and a copied one exposes itself: the host and time it names will not match the request it was copied onto.

To check a request you found in your logs:

1. 1. Find the request in logs that record full request headers — your application, reverse proxy or WAF. A default access log records the User-Agent only, and the receipt is not in it.
2. 2. Copy the X-EchelonGraph-Verify value and open it in a browser: it is a link to our verifier, and the receipt is checked on load. Or paste the X-EchelonGraph-Receipt token, or the whole URL, into the box at echelongraph.io/verify-scan.
3. 3. The verifier answers valid or not, and for a valid receipt echoes the host and port signed (as example.com:443), the name EchelonGraphBot and the time of issue. Valid, and matching the host and time on your log line, was us. Valid but naming a different host or time is a receipt copied from a different request, and was not.

What this does not give you. The receipt can only be checked against our secret, so you cannot verify it offline: you ask our verifier and take its answer, which is a degree of trust in us that a signature under a published key would not require. And when we rotate the key, every receipt issued under the old one stops verifying, so a genuine request from before a rotation will be reported as not genuine after it. We say this plainly because a verification scheme that quietly requires trusting the issuer is the thing this page exists not to do.

When there is no receipt. The receipt is emitted only when our signing key is mounted in the environment of the service that sent the request — the prober for a probe, our backend for the registration lookup. Without it the two receipt headers are simply absent, the User-Agent and From are sent as before, and the request is still made. So a request that names EchelonGraphBot and carries no receipt is either not ours or came from a revision running without the key. The prober and our backend each record at startup whether they have the key, and [email protected] will tell you which of those two cases it was. (Amended 26 September 2026, #2283: this said the key is mounted “in the prober's environment”, that “the probe still runs”, and “The prober records which state it started in”. Our backend has signed the registration lookup’s requests since 26 September 2026, and records its own state.)

This is the same receipt and the same verifier our Discovery Radars and the on-request Surface Scanner already use. An earlier version of this page specified a Radar-only header under a different name. It never shipped: the verifier at echelongraph.io/verify-scan already existed and already validated this format, and a Radar-only header would have meant building a second one.

One address is published, a machine-readable ranges file is not. The address is in What we promise above — 34.139.141.181, published on 8 October 2026 before any scanner used it, and the address Radar’s probes have left from since 17 October 2026 — and you can act on it today. Until 8 October 2026 Radar sent from 34.72.193.151/32, our main platform’s address. (Amended 8 October 2026: the address published here was 34.72.193.151/32.) What is still missing is this: a file you can fetch and diff, and reverse DNS that names us. When those land: we will publish the IP ranges Radar probes from, on this page, in a machine-readable form, and we will update that file before an address is brought into use, never after. Every source address will have reverse DNS resolving into a domain we control, and will forward-confirm — which neither address does: each reverse name is Google’s, as said above. That is the gap this section is still open for. It will forward-confirm — resolve the PTR, then resolve that name back, and it must return the address you started from. This is the same reverse-DNS confirmation pattern the major search crawlers use, and the practice Censys states for its own scanners: “The IPs we use have identifying rDNS, WHOIS, and an HTTP site that indicates ownership, intent, and contact information.”

We do not probe from residential proxies, from consumer VPN exit nodes, or from addresses we have not published. If you see traffic under our name from an address that is not listed, it is either not ours or a defect on our side — either way, tell us at [email protected] and we will tell you which of the two it was. We do not offer the file as proof that traffic is ours, only as the set outside which it should not be.

This section is the important one. Each line is a commitment, not an aspiration, and several are enforced by the prober's code rather than by anyone's memory.

Two of these mirror commitments the incumbents already make in writing, and we quote them so that our posture is recognisable rather than novel. Censys: “We never attempt to exploit vulnerabilities, bypass authentication, or access devices behind NAT.” Rapid7 Sonar: “At no point does Sonar bypass any technical barriers or otherwise access non-public-facing computers.” The ZMap paper puts the norm in general terms: “scan practitioners should refrain from exploiting vulnerabilities or accessing protected resources.”

On 7 September 2026 this section governed real requests to third parties for the first time, against 30 domains, once each. It governed real third-party traffic continuously from 9 September 2026 until Radar’s prober was stopped on 8 October 2026, and again since 17 October 2026: 5,231 probes of 5,231 distinct hosts in the 24 hours to 11:46 UTC on 19 September 2026, by our public feed’s count. That first run took a hash sample rather than the registry: a fixed one-in-two-hundred slice, the same domains every cycle rather than a rotating one that would have reached everyone eventually. We started there on purpose, because these rules had never governed a request to somebody else. It no longer runs over a sample at all — since 9 September 2026 the scheduler selects every domain in our registry, 9,616 of 9,999 active rows a day when last read on 24 September 2026, the difference being the excluded jurisdictions — at no more than one probe in 24 hours per host we do not own whose operator has not asked us for more. (Corrected 12 September 2026, #1806: this sentence read “Scheduled probing ran over one domain in every 200 in our registry”, and when the sampling constant was redefined on 9 September 2026 it was swapped into this past-tense sentence without rewriting it — so the page described the first run as covering every domain, in a sentence that then read “in our registry in our registry”, and still called it a fixed hash sample.) We stopped because our own sign-off record requires six controls to be recorded as verified running before a first third-party probe, and none of those six had been filled in. Nobody was harmed and nothing went wrong; the paperwork was simply not done, and doing it afterwards is not the same thing. What follows is the set of rules that bind us, stated so that they can be held against us; the status table at the foot of this page says, row by row, which of the mechanisms behind them exist today.

Radar's HTTP fetches are bound by robots.txt, per RFC 9309. The evaluator is wired to the probe path: every probe consults robots.txt before hop 0 and before every redirect hop, and a disallowed path is refused rather than probed. This page promised that would happen before any host that is not ours is probed. It did, and on 7 September 2026 hosts that are not ours were probed under it — 40 jobs, 30 probed, 10 refused at this step. Concretely, the rules are:

• • We fetch and cache robots.txt per host before probing it, and we match against our product token EchelonGraphBot and against *.
• • A Disallow covering the path we would probe means we do not probe it. There is no override, no allowlist of “important” hosts, and no exception for our own convenience.
• • Non-200 responses follow RFC 9309 §2.3.1, in the direction that costs us rather than you: a 4xx means the file is unavailable and we may proceed (§2.3.1.3) — except a 403 and a 429, which we treat as a complete disallow; a 5xx or a network error means the file is undefined and we assume complete disallow (§2.3.1.4) — with one exception we would rather state than have you find. If we already hold that host's robots.txt from an earlier successful fetch, §2.4 lets us go on using it while it is fresh enough, and we do: up to 24 hours normally, and up to 8 days while the host stays unreachable. A host we have never successfully fetched has nothing to fall back to and is disallowed outright. A host that is failing is never a host we probe harder.
• • 429 and 403 are our two deliberate departures from the RFC's literal text. RFC 9309 would treat both as ordinary 4xx and let us proceed. We treat each as a complete disallow. A host that answers “too many requests” has told us something and we intend to hear it. And a 403 on robots.txt is, overwhelmingly, a firewall refusing a client it does not recognise — not a site declaring it has no rules. Reading it as permission would mean the host most determined to keep us out is the one we grant ourselves the widest licence over, which is the opposite of what this page is for. §2.3.1.3 grants a crawler a permission rather than imposing an obligation, so declining it in these two cases breaks no conformance claim we make.
• • Corrected 12 September 2026, and stated rather than done quietly. Until that date this page said “429 is our one deliberate departure” and that a 4xx let us proceed without qualification. Both were true until a 403 began denying. We measured the effect before making the change, on 150 of the domains in our registry: 75.3% answer 200, 10.7% answer 403 and 9.3% answer 404. So it reaches about one host in nine, and a 404 — which really does mean there is no file — keeps its allow-all.

RFC 9309 §1 is explicit that “These rules are not a form of access authorization.” We agree. We treat robots.txt as an instruction we follow, never as permission we have been granted.

The gap robots.txt does not cover — and what we do about it

robots.txt governs HTTP requests. It has no counterpart at the IP layer. The ZMap paper says so directly: “there is no IP-level equivalent of the HTTP robots exclusion standard.” Reading your robots.txt at all requires a DNS lookup, a TCP connect and — on 443 — a TLS handshake. So a host that disallows us still saw one connection from us, and that connection unavoidably reveals reachability and certificate facts. There is no standard by which you can forbid the connection itself. Our position, stated as a rule rather than left implicit:

1. 1. Where robots.txt disallows the path we would probe, we do not probe it and we publish no observation for that host from that attempt. We do not launder the robots.txt fetch into a measurement.
2. 2. Because the standard gives you no IP-level way to refuse the connection, we provide one ourselves. That is what How to opt out is. Blocking our published ranges, or a verified exclusion, are the IP-layer equivalents of a Disallow, and we treat them with the same finality.

Politeness in Radar is enforced as cadence — how close together two requests may land — together with a cap on how many may be in flight at once, in shared state so that every prober instance charges the same budget for the same target.

The mechanisms above are implemented, their numbers are set, and since 7 September 2026 all eight are published on this page as figures. They are in What we publish about ourselves above: the rate, burst and in-flight cap per host, the same three per hosting provider, and the backoff base and its ceiling. Until that date this paragraph said they were not published, and said you were entitled to notice the difference — which you were. They are compiled into the prober, validated at boot, and refused if they fall outside the bounds the code enforces; the prober prints all eight on its boot line. The ninth — the minimum interval before any one host is probed again — is in force at 24 hours for every host we do not own whose operator has not asked us for more, and is enforced where it can refuse rather than where it can only schedule: for a stranger the prober claims a per-host slot before probing, so a second job for the same host inside that window is refused by the prober, not merely left unqueued by the scheduler. For a domain whose operator proved control and asked us to monitor it the same claim is made at the consented interval instead — the rung its operator chose, never under the published 30-second floor, and in practice no more often than once a minute today, because our scheduler sends a consented check no faster — and refused the same way (#1834; How often we re-probe you above). (Corrected 19 September 2026: this said the claim was made at “one minute today”; it is made at the chosen rung.) For a host we are publishing an open incident about, a re-check someone asks for is claimed in a one-hour slot of its own, beside the ordinary claim rather than instead of it: a second re-check inside that hour is refused the same way, and the ordinary claim is left as it was (#1903, the third exception above). For a host we own there is no such claim and the per-host budget is the control instead, which is the whole reason we can tell you it works. The scheduler is running, against the third-party domains in our registry — every active row outside the excluded jurisdictions, once a day each — and not against echelongraph.io, which self-probing last touched on 9 September 2026. The consumer — the prober that sends what the scheduler selects — was stopped on 8 October 2026 and has run again since 17 October 2026, so what it selects is sent again, from 34.139.141.181. (Amended 17 October 2026: from 8 October 2026 this said that nothing it selects is sent.) (Amended 8 October 2026: this sentence read “The scheduler and the consumer are RUNNING”.) (Corrected 19 September 2026: this said they were running against our own domain alone. That was true while a self-test list confined the scheduler to it, and false from 9 September 2026, when third-party probing was armed and that list removed — so for ten days this sentence told an operator we probed only ourselves while we were probing thousands of hosts a day.)
Corrected 8 September 2026: this passage said the interval was “in force at 24 hours” without qualification, that “the prober claims a per-host slot before probing” with no exception, and that the scheduler and consumer were “built and switched off”. The first two contradicted this page’s own §1.1, and the third was false while the scheduler was completing a cycle every few seconds. It was found by a post-close audit and not by us: the sweep that corrected the sibling sentence elsewhere on this page searched only the passage already being edited.

We aim, in the words Qualys SSL Labs uses for its own assessments, to be “slow, non-intrusive, and [to] not consume significant resources.” If we are not achieving that against your infrastructure, that is a defect on our side and we want the report.

Two tiers. The scheme follows Censys, whose opt-out is the reference implementation: the NDSS 2025 study Revealing the Black Box of Device Search Engine found that “Apart from Censys, none of the engines provide opt-out options, and most conceal their identity in the User-Agent.” That is a finding about the device search engines the study examined, not about scanners generally — other scanners plainly do operate opt-outs, and we quote two of them below.

The same study is worth citing against ourselves. Its Finding IV is that “Although Censys proposed the best practice of hosting a website on port 80 of each ScanIP to describe the scan's purpose and nature, no engines, including Censys itself, fully follow it in implementation.” That per-address ownership page is precisely what we commit to under Published source ranges above. We are holding ourselves to a standard that, on the published evidence, nobody currently meets — and, as at 18 October 2026, neither do we.

Tier 2 is real, takeable, and since 7 September 2026 it is on the path that stops a probe — but, as far as our last reading of the register shows (13 September 2026), it has never had to stop one, and we are not going to call that proven. Scheduled probing ran every day from 9 September 2026 until Radar’s prober was stopped on 8 October 2026, and again since 17 October 2026, so an exclusion registered now has something to stop. (Amended 8 October 2026: this sentence read “Scheduled probing is LIVE as at” the page’s status date, “so an exclusion registered today has something to stop”.) As at 18 October 2026 you can register an exclusion, prove the domain by DNS, and see it recorded; the verified list is published every 60 seconds, and our prober, when it runs, reads it every 30, so an exclusion reaches a running prober within 90 seconds. What no exclusion had done, when we last read the register on 13 September 2026, is stop a real probe, because nobody had completed one. Its probe engine and its robots fetch each ask an opt-out gate before every request and every redirect hop — and since 7 September 2026 the list they are handed on the scheduled path IS the register, reloaded every 30 seconds and fail-closed until it loads. Corrected 7 September 2026: this paragraph previously said the gate was “a fixed allowlist of our own hostnames, not the register”. That was true of the operator one-shot tools, which still use that narrower allowlist, and it stopped being true of the scheduled path when that path was built — we left the older sentence in place, and it understated what registering an exclusion does for you. What is still unproven is the last step: as at that last reading, no exclusion had ever stopped a real probe, because nobody had completed one. The mechanism is proven by its tests and by our own production logs; it is not yet proven by having refused somebody. Tier 1 is usable today — we publish the one address reserved for our scanning, and you can block it now — but not in the form it describes, because the machine-readable ranges file does not exist. And removing observations we have already published is still a commitment rather than a mechanism: the public feed at /radar publishes observations, and nothing yet removes a domain from it. (Corrected 13 September 2026: this read “because there is no public feed to remove anything from”.) [email protected] is monitored today and a request reaches a human.

Block our published source ranges at your edge. You do not need our permission, our agreement, or a reason we find satisfactory. We will not route around it.

You can do this today. The address reserved for our scanning is published: 34.139.141.181, above. It carries scanning and nothing else, so blocking it stops the scanning that sends from it, and none of our other traffic. Today Radar’s prober (since 17 October 2026), our Discovery Radars (since 18 October 2026) and our Surface Scanner (since 18 October 2026) send from it. What is missing as at 18 October 2026 is the machine-readable ranges file, which is a convenience rather than the mechanism. Block that address, or block the source addresses you have observed, and tell us at [email protected]; we will confirm which addresses are ours so that your block is complete rather than approximate. Read the caveat above if you blocked the address we published before: 34.72.193.151/32 carries our other services too, so blocking it stops our main platform’s traffic, mail included, and it does not stop Radar, whose probes have left from 34.139.141.181 since 17 October 2026. It does not stop our Surface Scanner either, which has sent from 34.139.141.181 since 18 October 2026. (Amended 18 October 2026: this said that blocking it “does still stop our Surface Scanner, which sends from it until it is moved”.) Until 8 October 2026 our Discovery Radars sent from Google Cloud’s shared addresses, not from either address (see What we promise), so neither block stopped them. Since 18 October 2026 they send from 34.139.141.181, so a block of it stops them too. For a domain, the register under Tier 2 below reaches five of them, with the limits stated there.

Here is what that does and does not achieve, stated as plainly as Censys states it — “Blocking connections from Censys' subnets prevents our scanners from indexing your services. However, this does not remove historical data from Censys datasets.”

For a domain this is self-service, and it does not require contacting us. Ask for the exclusion, publish one DNS record to prove you control the name, then tell us the record is there. No account, no reason, and no agreement from us:

Asking changes nothing on its own. Only the verified state excludes anything, and that is what the DNS record is for: an unverified exclusion list is a mechanism by which a stranger could remove your domain from a public record without your knowledge. Verification protects you, not us. scope is radar, surface-scanner or all, and defaults to all. Be aware of what that scope does and does not reach today: the register is read by Radar's prober; by the part of our backend that refuses to queue a re-check of a host that has opted out; by the registration lookup in our backend that fetches a domain’s RDAP record from its registry for the domain’s Radar page; and by five of the Discovery Radars on our Responsible Disclosure page — the AI-Exposure Radar, the Shadow AI Radar, the Exposed Data-Stores Radar, the Exposed AI Keys & Config Radar and the Subdomain Takeover Radar. The registration lookup does not look up a domain that has opted out, and does not follow a redirect to a host that has. The first three are Radar. The five Discovery Radars ask under the radar scope, so a verified exclusion scoped all or radar stops them and one scoped surface-scanner does not. Each asks before every request it sends to a host and every redirect it follows — the AI-Exposure Radar’s catalogue GETs, its MCP POSTs (server/discover, which under the 2026-07-28 revision opens no session, so a server that answers it with a DiscoverResult, or with an error that revision defines, is sent no further POST and is not written to, and the older initialize handshake only when that is refused), the DELETE that closes a session a POST opened, each OAuth protected-resource metadata GET and the GET that reads the first event of the older SSE transport’s stream; the Shadow AI Radar verifier’s page, redirect and API requests; the Exposed Data-Stores Radar’s web probe and database connections, which it addresses to an IP, as below; the Exposed AI Keys & Config Radar’s HEADs and GETs, including the listing check of a storage bucket the homepage references; and the Subdomain Takeover Radar’s GETs, having asked about the host before resolving its name — and sends nothing when the register says the host is excluded or cannot be read. When they run, they read the register from our database every 30 seconds, and with no copy younger than ten minutes they send nothing to any named host. A request the register refuses is not a measurement, so it records nothing — no verdict and no finding. A revoked exclusion stops applying at the next read, and the host can be probed again. The register holds names, so a request addressed to an IP address is covered only through the host names a scan index attributes to that address — and the Exposed Data-Stores Radar addresses every data-store probe that way, to the address and port a scan index reported. It asks the register about every host name that index’s record (Shodan’s or LeakIX’s) lists for the address, and sends the address nothing if a verified exclusion covers any of them, or while the register cannot be read. The Shadow AI Radar does the same for an address it took from Shodan, through the host names Shodan lists for it. An address no scan index attributes to your domain is still probed, and so is a Shadow AI Radar address until a Shodan sweep has recorded its host names; for an address or a range, email [email protected] (below). Not everything we send toward a domain reads the register: the Email Spoofability Radar does not, and may still read your domain’s public DNS records (its MX, SPF and DMARC records); and when we prepare a disclosure to your domain we fetch its security.txt without consulting it. Our Surface Scanner does not consult the register either, so a scope of all records your intention across our scanners and currently binds only Radar and those five Discovery Radars. We would rather you knew that than discover it. (Amended 4 October 2026, #2478: this read “An address no scan index attributes to your domain is still probed, and so is an address the Shadow AI Radar took from Shodan, which it asks about as the address alone”; the Shadow AI Radar now asks the register about the host names Shodan lists for the address.) (Amended 28 September 2026, #2358: this read “The register holds names, so a request addressed to an IP address is not covered — and the Exposed Data-Stores Radar addresses every data-store probe that way … as the Shadow AI Radar does for a result it took from Shodan. A verified domain does not stop those probes”; the Exposed Data-Stores Radar now asks the register about the host names a scan index lists for the address.) (Amended 27 September 2026, #2323: this read “… and by the AI-Exposure Radar, one of the Discovery Radars …”, said “The other Discovery Radars that send requests to hosts do not read the register yet” — the Shadow AI Radar’s verifier, the Exposed Data-Stores Radar, the exposed-config radar and the Subdomain Takeover Radar — “so a verified exclusion does not stop them today”, and said a scope of all “currently binds only Radar and the AI-Exposure Radar”; all four now ask the register before every request they send.) (Amended 27 September 2026, #2321: this read “… and by the registration lookup … All three are Radar”, and said a scope of all “currently binds only the Radar side”; the AI-Exposure Radar reads the register too, and it is a Discovery Radar, not Radar.) (Amended 26 September 2026, #2281: this read “… and by the part of our backend that refuses to queue a re-check of a host that has opted out, and by nothing else”; the registration lookup reads it too, and it is still Radar.) (Amended 19 September 2026, #1903: this read “the register is read by Radar’s prober and by nothing else”; the re-check’s backend reads it too, and it is still Radar.) A verified domain covers every name beneath it, so proving example.com excludes api.example.com too — you do not have to enumerate your hostnames.

For an IP range, email [email protected] instead. The self-service register is by domain name and refuses an IP address outright, because an IP is not a name anyone can prove control of through DNS and we would rather refuse than half-honour it. For those we verify control from publicly verifiable records — RDAP/WHOIS — in the manner Rapid7 describes for Sonar: “we attempt to verify that the requestor has been delegated or otherwise controls the network addresses … typically … via WHOIS and other tools.” Censys states the same test: “We honor opt-out requests from operators who can verify network or domain ownership through public WHOIS data.”

Once verified, a Tier 2 exclusion:

• • Partly live is recorded, published to our prober within 90 seconds, and is the list the prober checks before every scheduled request. It had stopped no probe when we last read the register, on 13 September 2026, only because nobody had completed an exclusion. Corrected 7 September 2026: this bullet read “not yet the list the prober checks before a request, so it stops no probe today. Nor does it need to: we probe only our own hostname”;
• • Not yet removes the excluded scope from the public Radar feed, including observations already published for it — a commitment, not yet a mechanism: the feed publishes, and nothing yet removes a domain from it (corrected 13 September 2026; this read “no feed exists to remove anything from”); and
• • Live today is honoured regardless of your reason. We do not require one.

It still cannot recall copies third parties already hold.

What is actually built, stated so you can hold us to it. The gate is written to fail closed: given no readable register it answers “unknown”, and the engine turns that into no request rather than into a probe — and after ten minutes without a readable copy that is its answer for every domain, so a register we cannot read stops probing rather than letting it through. Restored 7 September 2026: the paragraph below calls the ten minutes “the one that matters” and this page had stopped saying what it was. That property is real and tested, and it is why we were comfortable wiring it in its own change rather than shipping something permissive early. Two honest edges: a register of domain names has no opinion about a hop addressed to a bare IP address, so that one case is allowed through rather than refused; and the fail-closed behaviour, while it now governs every scheduled request, had never been observed refusing one when we last read the register, because no exclusion existed to refuse. The 90 seconds is two scheduled steps — one to publish the register, one for the prober to read it — so it is what you should expect in normal operation, not a guarantee: a step that fails is not retried until its next turn, which adds another minute or another thirty seconds. The ten minutes does not stretch, and it is the one that matters, because it is the point at which we stop rather than carry on. But when we last read it, on 13 September 2026, no verified exclusion was in force. That is measured, not assumed: the list our prober loads is built from exclusions that completed DNS verification, and on 8 September 2026 it held zero; re-read from the prober’s own load line on 13 September 2026, it still held zero. We have not re-read it since, so we do not state it for any later day. A request that has not completed verification is not on that list and excludes nothing. Corrected 8 September 2026: this said “nobody has asked”, which we cannot show — we can show that nobody has completed one. Radar now probes third parties, so there is something for an exclusion to bite on; at that reading there was simply no exclusion. (Corrected 19 September 2026: this sentence dated that reading to the page’s status date rather than the day it was taken.) So the mechanism is proven by its tests and by our own production logs, and not yet by having stopped a real probe of someone else's infrastructure. We would rather say that than let the word “enforced” do work it has not done.

We would rather adjust than exclude, and we will say so once. If the problem is our cadence, our timing window, a particular hostname, or the way something is worded rather than the probing itself, say so and we will change that instead. But we will not make an exclusion conditional on hearing us out first.

Exclusions expire, and are re-verified

A Tier 2 exclusion runs for 12 months. Before it lapses we contact the verified address to ask whether it should continue; if it should, we renew it. Two reasons, both of which are the incumbents' own: operators often change their mind once they know what we are — Censys reports that “many operators rescinded their request for opt-out after understanding our scan intent” and that “many initial emails are sent by automated processes” — and a stale exclusion list is its own problem, because network blocks and domains change hands; Rapid7 re-checks in order to “remove stale entries where the WHOIS record has changed”, and so do we.

That re-contact is not a running process yet, and we would rather say so than let you find out. Nothing expires today — an exclusion stays in force until you tell us otherwise, and there is no expiry field for anything to act on. The self-service register also has no field for your contact details, by design: it records the domain, the scope, the token we asked you to publish, the request’s state and when each step happened, and — only if you send one — a free-text note. So for a DNS-verified exclusion there is currently no address for us to write to, unless you chose to put one in that note. Treat the twelve months as the point at which we owe you a question, not as a clock that can take your exclusion away. (Corrected 19 September 2026: this said the register records “only the domain, the scope and the proof you published”; the request also accepts an optional note, and we keep it.)

Expiry is not a trick to resume probing. If we cannot reach you, or you do not reply, the exclusion stays in force — silence renews it. Only an affirmative “you can resume” from a verified contact lifts one.

Prior art — the wording we modelled this on

We did not invent this posture. Qualys SSL Labs has run public, named per-server assessments for over fifteen years, and its opt-out is the most gracious in the industry — unconditional, apologetic, and offering to adjust before it offers to exclude:

“We apologize for any inconvenience that our scans may be causing for you. If you have a problem with how we're scanning, please get in touch. We will be happy to adjust our scanning so that it does not bother you. If, on the other hand, you object to your public web servers being scanned, we will add you to our black list … and you will not be scanned again.” — Qualys SSL Labs

The one place we depart from SSL Labs is verification: their list is unverified, ours is. We think that is the right trade for a feed where an exclusion also removes published records, for the reason given above.

Radar's purpose is to publish measurements about named third parties, and some of them will sound adverse. That obliges us to be correctable.

How to dispute an observation. Email [email protected] with the domain, the observation and what you say is wrong with it. You do not need to be a customer; there is no charge; and there is no contract to sign. Every observation carries the timestamp at which it was measured, so a dispute can be about the measurement, the method, or the fact that the world has moved on since.

A disputed observation is marked as disputed while it is unresolved. Not yet That is a commitment, and it is not yet built: the public feed exists and publishes as at 18 October 2026, and the dispute machinery does not. (Corrected 13 September 2026: this read “neither the public feed nor the dispute machinery exists” and promised the marking “before the feed carries its first observation” — the feed carried observations before the marking existed, so that promise was not kept and is withdrawn rather than re-dated.)Disputes reach a human at [email protected] today; what does not exist yet is the marking itself, on a feed that is now live. We adopt the dispute principle of the US Chamber of Commerce Principles for Fair and Accurate Security Ratings: “Rated organizations shall have the right to challenge their rating and provide corrected or clarifying data. … Disputed ratings should be notated as such until resolved.” The marking will appear alongside the observation, where a reader sees it — not on a page an operator has to know to ask for.

We do not adopt the same code's confidentiality principle, and we would rather say so than quote the code selectively. That principle reads: “Rating companies should not publicize an individual organization's rating.” Its signatories acted on it, and Radar plainly does publish, against a named domain, in public. Our position is that the principle is addressed to a company-level rating, and that what Radar publishes is a per-endpoint measurement in the manner of Qualys SSL Labs' per-server assessment, not a rating of your organisation. That distinction is the entire basis on which we publish at all. It is a judgement call rather than settled ground, and we are aware that a reader may weigh it differently.

How we resolve one.

1. 1. We re-measure. Most disputes are resolved by the current state of the endpoint, not by argument.
2. 2. If the observation was wrong, we correct it and say so; corrections carry the date of the correction.
3. 3. If we still believe the measurement is right, we tell you why, we show the method, and the dispute marking stays visible until the disagreement is resolved or the observation is superseded by a fresh measurement.
4. 4. An exclusion request is always available and is never conditional on the outcome of a dispute.

What we publish and what we do not. We publish the measurement and its timestamp rather than a characterisation of your organisation, and we state the method. We do not publish a company-level score, and we do not comment publicly on an individual organisation's posture outside the feed itself.

This table exists because a policy that describes mechanisms which do not yet exist is worse than no policy. It is accurate as at 18 October 2026.

We will not turn scheduled probing on before this page is live at the URL our User-Agent advertises. A bot whose identity link returns 404 does not have an identity.

We hold ourselves to what we ask of others. Our security.txt is published at the location RFC 9116 requires, under /.well-known/, with both mandatory fields — a Contact and an Expires set less than a year ahead — and with Canonical URIs for both the marketing and application hosts.

Where we contact an operator about something we found, we read your security.txt first, as RFC 9116 §5.8 asks. We also observe §5.5: “researchers shouldn't assume that the presence or absence of a 'security.txt' file grants or denies permission for security testing.” A security.txt on your site is a route to a human. We do not read it as authorisation, and we do not read its absence as a refusal — How to opt out is how you refuse.