Why we asked your server for a page
UptimeWarrior is a website monitoring service. This address is printed in the user agent of every request we make, which is how you got here. Something we were asked to watch either is your page or links to it.
Nothing crawls on our behalf: there is no third-party scraping network and no proxy pool. Every request described on this page is made by the service itself.
One page, not a crawl
We request the exact address we were given. We do not spider a site, follow its internal navigation, or look for pages nobody pointed us at.
No JavaScript
Plain HTTP requests. Nothing is rendered and nothing is executed, so a single-page app looks to us like whatever its server returns.
The page is not kept
We store the status code, the response time and what the checks concluded. The HTML is read, capped at 2 MiB, and discarded.
01 / what it is
What we request
Four things, and only the first two are HTTP requests to your server at all.
The page
One GET to the address on the account, following at most 5 redirects. We read the status code, how long the response took, and the HTML (for the title, description, social image, mobile viewport and charset). If that request fails, the same GET is made once more 30 seconds later, so that one failed request is not reported as an outage.
The links on it
Every <a href> on that page gets one HEAD, and a GET afterwards only if the HEAD was rejected. Some servers answer HEAD with a 404 or a 405 on a URL that is perfectly alive, and we would rather confirm than report a working link as dead. Up to 50 links per page, at most 10 in flight at once.
The certificate
A TLS handshake, read twice: once for the expiry date and once to check the chain verifies. No HTTP request is made.
The domain
An RDAP or WHOIS query to the registry for the renewal date. This never touches your server.
If you are not a customer of ours, the second one is almost certainly why you are here: a page we were asked to watch links to yours, and we followed that link to see whether it still answers. One request per link, per scan.
02 / how to verify
How often
Only the page fetch runs on every cycle, and the cycle depends on what the account pays for. Everything heavier is on a slower clock of its own, which is why a link on a monitored page hears from us at most every 6h rather than every minute.
The page
- Free
- 15 min
- Pro
- 60s
- Agency
- 60s
The links on it
- Free
- weekly
- Pro
- every 12h
- Agency
- every 6h
The certificate
- Free
- hourly
- Pro
- hourly
- Agency
- hourly
The domain
- Free
- not on this plan
- Pro
- every 6h
- Agency
- every 6h
There is one other source: a free scan, which anyone can run once against any address without an account. It is a single pass. It is capped at 25 links, held to a total time budget and rate-limited per visitor and per target domain, and nothing about it is stored.
03 / opting out
If you would rather we did not
We do not read your robots.txt
We would rather say so here than leave you to find out. A monitored page is requested because whoever runs it asked us to, and a link is requested once to see whether it answers. Neither is a crawl, so neither consults robots.txt. If that is the wrong call for your server, the two options below both work.
Block the user agent
Match the agent from your log line at your edge and every request described on this page stops. Whoever links to you is then told we could not check that link, and shown the status you turned us away with. They are not told the link is broken: a refusal is not evidence of that, and we do not report it as though it were.
Or tell us
Use our contact form and give the address we requested. Include a log line if you have one. It tells us which of the four requests above it was, and that is usually the whole diagnosis.