What this is, and why it queried your server

How often

No sweep runs on a schedule. Each one is started by hand, so a server sees a burst of requests and then nothing, possibly for weeks, rather than a visit at the same time every day. The one full sweep of this list so far took 1h26m21s.

That is what is true today and not a policy. If sweeps later run on a timer, this paragraph is what has to say so.

How politely

These are the prober's defaults, and they are the numbers a single operator sees:

• 2 seconds at least between two consecutive requests to one host and port, measured from the end of one to the start of the next, so a slow answer never shortens the pause that follows it.
• 4 hosts at once, at most. That counts hosts and not endpoints: endpoints are grouped by host and port, and one request to one of those groups is in flight at a time however many endpoints it holds. If you run several of the endpoints on the list behind one host and port, they are probed one after another, not together.
• 2 requests per second in aggregate, across every host in the sweep, which is what those two numbers come to together.
• 6 requests to one endpoint in one sweep, one per check that is cheap enough to run by default, plus one more for each redirect followed.
• 20 seconds is the longest Retry-After that is waited out, and it is waited out once. A longer delay is read as "come back after this sweep", so the throttle is recorded and the request is not repeated.
• 30 seconds and one request is abandoned.
• 60 seconds and one check is abandoned, pause and retry included.
• 600 seconds and this endpoint's whole turn is abandoned and the sweep moves on. Nothing keeps knocking.

Both of the first two numbers count a host and a port, and not a machine. Two endpoints on one server behind different ports are two as far as the pause and the count go, so they can be probed at the same time with no enforced gap between them. That is not hypothetical on this list: it carries http://eculture2.cs.vu.nl:8890/sparql and http://eculture2.cs.vu.nl:5020/sparql/, and those two are probed together. The reason is that two SPARQL engines on one host are usually two services and serialising them would halve the sweep's throughput for no politeness gain; the cost is that they are also one machine's processor and one network link. If that is your machine, the section below is the way to say so.

If your endpoint is marked dormant

Dormant is a place in this service's rotation, and it is nothing else. An endpoint marked that way is not asked in every sweep. It stays on the list, its page stays up, and the verdicts on that page stay exactly as the last sweep that really asked recorded them, with that sweep's own instant printed beside them.

It is not a verdict, and it is not a claim that your server is at fault. The checks this site publishes have a closed set of six values and dormant is not one of them: it says something about us. It is not drawn as a finding, it gets no mark against any check, and nothing here concludes from it that your endpoint does not work.

Three different things put an endpoint here, and the page that sent you says which. automatic is this service's own admission policy setting an endpoint aside on cost and silence. operator-hold is a person setting one aside by hand. not-in-this-sweep is neither, and it is described last. These are not three wordings of one thing: they differ in what was observed, in how often the endpoint is asked afterwards, and in what ends it. Read the one your row or your endpoint page names, and not the others.

Set aside automatically, and what was actually observed is narrower than the word may sound. In each of 2 sweeps in a row, the checks sent to that endpoint together spent longer than the first number below, and not one of them came back with something that could be counted as an answer: the time went on checks that were cancelled when their own budget ran out. A server that accepts the connection and then holds it open produces exactly that, and so does one that is merely slower than the budgets allow. Which it was is not something this project measured, and the mark does not say. An endpoint set aside this way is asked at most one sweep in every 7 days, and only when a person starts one, rather than in every sweep.

These four numbers are that case, and only that case:

• 60 seconds of cancelled checks, added up over one endpoint in one sweep, is what counts that sweep against it. The threshold was chosen to sit clear of the endpoints on this list that do answer slowly, which are the ones a lower number would have caught.
• 2 sweeps in a row have to look like that. One would have been enough for almost all of them; the second is bought for the endpoint that spent minutes in one sweep and seconds in the next, which one sweep would have set aside for a bad afternoon.
• 7 days at least between two sweeps that ask an endpoint this service set aside itself. A bound and not a timetable: if nobody starts a sweep for a month then nobody asks for a month. When the endpoint does answer one of those sweeps it goes straight back into every sweep, with no request from anybody and no edit by anybody. An endpoint held by hand is not on this clock at all.
• 7 days is how long an endpoint put back into every sweep by hand cannot be set aside again automatically, whatever it costs in the meantime. That is what the message below buys, if what you want is to be probed.

Set aside by hand, and then nothing at all was observed. A hold is not a measurement and it is not a threshold: a sweep skips a held endpoint before it sends it anything, so no cancelled check and no cost figure lies behind the mark, and none of the four numbers above is what put it there. Neither is the cadence. A held endpoint is never asked, by any sweep, until a person lifts the hold, and it cannot answer its way back in because it is not asked. A hold put on by hand comes off by hand, at the address below. This site publishes that a person set the endpoint aside and not what for, because the reason may be one no verdict here expresses, and guessing at it on your behalf is the one thing this page will not do.

Not asked by a sweep that was repeating an earlier one, which is not a relegation at all. A sweep can be told to re-run an instant that has already run. It then asks exactly the endpoints that instant asked, so an endpoint it did not reach is one that was not in the earlier sweep either, and the run graph records that with the reason not-in-this-sweep. Nothing was observed, nothing was decided, no threshold was crossed and how often the endpoint is asked is exactly what it was before. If that is the reason your page names, none of the four numbers above applies to you and there is nothing here to overrule; a page that reported it as either of the two cases above would be describing a decision about your server that nobody took.

A person changes it, either way, at the address this page already publishes. Email michel.dumontier@maastrichtuniversity.nl and say which endpoint and which way. Nothing watches that mailbox: somebody reads the message and runs a command on the machine that holds the file, by hand, and there is no automation between the two and no service level attached. There is no button on this site, because this site is read-only and the decision lives on that machine and not here.

Why your endpoint is on the list

Because a public dump of dataset metadata named it. Nobody opted in.

The list was generated from the LOD Cloud dump of 2026-06-15, https://lod-cloud.net/versions/2026-06-15/lod-data.json. That file carried 725 endpoint entries, which came to 548 distinct URLs, of which 543 are on the list a sweep reads. The difference was dropped by rules that refuse a URL carrying credentials, a reserved documentation name, or a string that cannot be published as an identifier, and by one more that runs only where the list is generated: an entry naming a private or loopback address is dropped as the list is written, and one of the five refusals recorded for this dump came from that rule. A list handed to a sweep directly is not filtered for those addresses, which matters only to whoever is running the prober, since such an address names their own machine or a network reserved to receive nothing.

So an endpoint on the list is one somebody registered as public, and that is the only claim being made about it. It is not a claim that its operator wants it probed, which is what the next section is for.

How to ask not to be probed

Blocking the requests may or may not reduce them, and which kind of rule you write is what decides that. An endpoint that refuses us quickly, with a reset or an HTTP error, costs this project nothing, so nothing about it sets the endpoint aside: it is recorded as unreachable and asked again on the next sweep, at the same rate. An endpoint that silently drops our packets is the case the admission policy above notices, because every check then runs until it is cancelled, which is exactly what that policy measures: after 2 such sweeps in a row the endpoint is marked dormant and asked at most one sweep in every 7 days rather than once per sweep. That is fewer requests. It is not none of them, it takes two sweeps to arrive, and it is a decision about our own rotation that we can change without telling you. The list below is the thing that works.

Email michel.dumontier@maastrichtuniversity.nl and say which host to leave alone. A log line pasted in helps, and nothing more is needed. The address is a mailbox rather than a service on this machine, so it does not depend on this site being up.

Exactly what happens then, including what it does not do:

• A person adds the entry. Nothing watches that mailbox. Somebody reads the message and writes your host into registry/exclusions.toml by hand. There is no automation between a message arriving and that edit, and no service level attached to it.
• Once the entry is there, it takes effect at the next sweep. The file is read from disk at the start of every run, so no rebuild and no redeployment stands in between. A sweep already running finishes under the list it started with.
• Nothing already published is retracted. An exclusion stops future probing. It does not remove past measurements: they are written once and never rewritten, and the endpoint's URL is part of the identity of every fact about it.
• One entry covers one whole host, and only that host. Every scheme, port and path on it is covered, and nothing below it is: example.org does not cover sub.example.org. Names under one domain routinely belong to different people, so an operator who runs several of them lists them all.
• Nothing is resolved. A second name for the same server, or an alias, is not covered unless it is listed too. Nothing asks a resolver what an entry points at, so two names for one machine are two entries.
• A host written as an IPv6 literal cannot be entered at all. An entry is a bare host name, and the file refuses anything carrying a colon, so [2001:db8::1] has no spelling that would be accepted. No endpoint on the list is written that way today, so this excludes nobody now; it is here because the entry above says one entry covers one whole host, and this is the one host it cannot.
• An entry publishes the host it excludes. registry/exclusions.toml is committed to this project's public source repository, and the reason given is copied into a log line each time the rule fires. No person is named in it. A hashed entry was considered and rejected: nobody could then check it, including the person who asked.

The file is named here because it is checkable. If you have asked, you can look and see your host on it, which is the only way this promise can be verified from outside.

What this site does not do

Listed rather than left to be discovered, so nobody hunts for a page that is not here.

• No leaderboard, and no sorting by anything. The index has one text filter.
• No page per check, so nothing writes out how a check is computed or lists which endpoints fail it.
• No history. Each endpoint shows the newest sweep that measured it and nothing before that.
• No charts and no graphs of any kind.
• No faceted search.
• No query editor. Nothing here sends a query you type.
• No public SPARQL endpoint of our own, which is worth saying plainly given what this project measures. The RDF representation of each page is what there is instead.
• No browsing by vocabulary or by class, which the design does call for. That one is not merely unbuilt: it needs content data this project does not yet gather, which is a later stage of the plan. Asking again after that stage lands is worthwhile in a way it is not for the items above.