Why we probe unclaimed servers every 12 hours

Every report page states which cycle the server is on. The numbers are 12 hours, 8 hours, and 15 minutes. None of them is arbitrary, and none of them is a promise about anything that happens between two probes.

12 hours for servers nobody asked us to check

An unclaimed server is one whose maintainer has not shown up. Usually we found it in a public registry and read its robots.txt, and we are observing it as any client could. That is legitimate, and it also means we are a guest. A guest does not knock every fifteen minutes.

Twelve hours is the slowest cadence that still tells a reader something useful:

• Two probes a day catch day and night. They land twelve hours apart, so a server that is only up during someone’s business hours misses one of them every day, and a day with an unanswered probe is never shown as a clean day.
• It is enough to see a changed tool set. Tool sets and schemas on unclaimed servers change on the scale of releases, not minutes. A fingerprint taken twice a day records the change within half a day of it happening, which is as precise as anyone needs for a server they haven’t claimed.
• It keeps the load negligible. Each probe is a handful of requests. Two per day for each directory listing is below the noise floor of any server’s own health checks; a host with several listed endpoints gets that for each of them.

The online rate in the directory is the share of days, in a window that starts at the later of our first observation of that server and 90 days ago, on which the endpoint answered every one of our probes, out of the days on which we know either way. A day on which any probe got no answer — the host name did not resolve, the connection failed (counted since 2026-09-27), or no complete response arrived within the probe’s time budget — or, since 2026-09-23, on which the handshake was answered with a 5xx, counts against it. A day on which the only probes that could not conclude were our own doing — we were rate-limited, or our own policy declined to connect — is left out, the same as a day we never got to. We show it as a whole percentage, next to the number of days it was computed over.

8 hours once the maintainer is here

A claimed server on the Free plan moves to every 8 hours. The maintainer has proved they control the endpoint and has asked to be checked, so we are no longer a guest. Three probes a day is a meaningful step up in how soon a changed fingerprint shows up, and in how likely a short outage is to be seen that day, without turning into monitoring.

15 minutes on Indie

Indie is the plan for people who want the probe to behave like a contract test in a CI pipeline: frequent enough that a release which breaks the handshake is caught, and one that changes a tool schema shows a new fingerprint, before the next one ships. Fifteen minutes is the shortest interval we offer today, and it is the interval at which a failure email reaches you while the release is still fresh, rather than hours later.

What the cadence does not mean

The most important sentence on the methodology page is the one people skip: we do not guarantee an endpoint’s behaviour between our runs. A server on the 15-minute cycle can be down for 14 minutes and show a perfect record. A server on the 12-hour cycle can have a bad afternoon we never see. The report shows when we looked and what we saw. Anyone who reads it as continuous monitoring is reading more than is there, and the page is written to make that reading hard.

Paying moves your server to a faster cycle. It does not change what any probe observes or how any row is judged. Beyond cadence, money buys room for more claimed servers (ten per subscription instead of one) and a live README badge instead of a static one, and nothing else, on purpose. One side effect is worth knowing: the directory’s default order is most recently observed first, so a server checked every 15 minutes tends to sit near the top. That is a consequence of the schedule, not a ranking.

A note on the schedule itself

The probe wakes every five minutes and claims the servers that are due, up to a fixed number per wake-up; anything left over waits for the following wake-ups, another batch every five minutes. Servers we discover are given start times spread across the rounds, so that load is spread across the day instead of arriving in one burst at midnight. A server that asks us to slow down, with a 429 or with a 503 that carries a Retry-After header, is honoured: we stop that round, its next probe is never scheduled earlier than a delay it gave in seconds (capped at 24 hours), and the checks that did not run are shown as not checked, with that reason, rather than failed. Being a polite client is part of the methodology, not an operational detail.