Uptimeify Bots: What They Fetch and How to Block Them

You are most likely here because you found one of our names in an access log and want two answers: what is this, and how do I stop it. Both are on this page, and neither needs an email to us first.

We run three automated clients against the public internet. Each identifies itself, each comes from a published set of addresses, and each can be blocked at your edge. One of them runs on a check interval somebody on your own side chose, and blocking that one has a consequence worth reading before you do it.

Our bots

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36 SiteMonitorBot/1.0 (+https://uptimeify.io)

Addresses and verification

Every scheduled check comes from a fixed, published fleet. The list below is generated from the nodes that are actually active right now, not from a copy someone maintains by hand, so an allowlist built from it stays correct when the fleet changes.

For firewall configuration snippets per vendor, see the firewall documentation. If you would rather automate it, /ips.txt is plain text, one address per line, and cached for five minutes.

Check whether we get through

If you already run a rule and want to know what it does to us, ask us to fetch you. We request the address with the SiteMonitorBot user agent and show you the answer your own server gives.

This asks your server and reads its response, nothing more. It does not tell you whether the address is monitored with us, by whom, or how often, because that would answer a question about someone else's account to anyone who can guess a hostname.

Why this is in your log

What we hold ourselves to

Our checks run against infrastructure we do not own, so the limits matter more than the intentions. These are the ones that are enforced in code, not aspirations:

• We identify ourselves. Every scheduled request carries a name and a URL that resolves to this page. The one exception, the keyword and expected-response checks, is named above rather than left for you to discover.
• We back off instead of retrying. A failed status-page read waits for the next cycle. It does not hammer a host that is already struggling.
• We ask for as little as possible. Conditional requests mean an unchanged status page answers with HTTP status code 304 and sends no body at all. Reachability checks read no body to begin with.
• We stay where we were pointed. Redirects on a status-page read are a failure, not an invitation. Nothing decides at runtime to fetch a host that was never validated.
• We publish where we come from. The address list above is generated from the live fleet, so blocking or allowlisting us never depends on us remembering to update a page.

What we do not do: read robots.txt. A Disallow costs you ten minutes and changes nothing on any of the three clients. A rule at your CDN, WAF or web server works immediately.

Blocking us

Match on the substring, never the full user agent string, and reject the request. Cloudflare, as a custom WAF rule expression:

(http.user_agent contains "SiteMonitorBot") or
(http.user_agent contains "UptimeifyStatusBot") or
(http.user_agent contains "UptimeifyToolsBot")

nginx:

if ($http_user_agent ~* "(SiteMonitorBot|UptimeifyStatusBot|UptimeifyToolsBot)") {
    return 403;
}

Apache 2.4:

<If "%{HTTP_USER_AGENT} =~ /SiteMonitorBot|UptimeifyStatusBot|UptimeifyToolsBot/">
    Require all denied
</If>

To stop the keyword and expected-response checks as well, block the addresses in /ips.txt rather than the names, those requests carry a plain Chrome user agent.

One consequence to weigh first: blocking SiteMonitorBot stops a check somebody on your own team is relying on, and it will start reporting a false positive, an outage that is not happening. That is also why these are three separate clients rather than one, blocking any of them should never silently take out the others.

Contact

Something wrong, too frequent, or simply unwanted: hello@uptimeify.io. We read this address and answer.