If you run a website and just saw Umpire in an access log, this page is
for you. It explains exactly what the probe does, why it fetched your page, and how to stop it in one email.
A customer bought a verdict from Umpire and their acceptance spec named one of your public URLs: an agent claimed it published, deployed, or updated something there, and the customer paid for a neutral party to check whether the public state agrees. The probe fetches that URL, records what it saw, and nothing else.
| behaviour | guarantee |
|---|---|
| method | GET only. Never POST, never a form submission. |
| volume | At most three fetches per purchased verdict, and one purchase does not repeat: a sworn verdict fetches once more about a minute later, then stops. |
| spacing | A politeness gap between any two fetches to your host, across every customer. |
| redirects | Follows at most 4 hops, and records each one. |
| size and time | At most 2 MB read per fetch, 12 seconds timeout. |
| refusals | A 403 or 429 from you fails the customer's check. The probe does not retry aggressively. |
| identity | Always the user agent above, with a link back to this page. Never spoofed. |
The signed verdict carries an observation of the response: the final URL, the HTTP status, the address the response came from, the TLS certificate details, a handful of standard headers with values capped at 200 characters, and the sha256 of the body. The body itself is not kept. Anyone can fetch the same URL and compare hashes, which is the whole point.
Either of these works, and neither needs a reply from us:
We do not ask why. Blocks are honored on the domain, not negotiated per URL, and a blocked host never appears in a new verdict again.