The HowlOps monitoring bot

If you found this page in your access logs, one of your own customers asked us to check that their site is up. We are an uptime monitoring service, and the traffic you are seeing is that check.

What it does

It makes a single request to one URL that a customer of ours configured, and records whether it answered, how long it took, and the status code. It does not crawl. It does not follow links, read your sitemap, index content, or fetch assets. One request, one URL, on a schedule.

How often

The customer chooses the interval, most commonly once a minute. When they have asked for checks from more than one part of the world, you will see one request per interval from each of those regions. If a check fails we may retry it shortly afterwards to tell a real outage from a blip.

Where it comes from

These are the addresses we probe from. Allowlist them if our checks are being blocked. The same list is published as JSON at /bot/ips.json in the usual published-bot-IP-list format (a creationTime and a list of CIDR prefixes), so a firewall rule or a bot directory can consume it directly. A longer form with region names is at /api/v1/public/probers.

How to recognise it

Our checks identify themselves by default as Mozilla/5.0 (compatible; HowlOpsMonitor/1.0; +https://howlops.com). A customer can set a different User-Agent for their own monitor, so the addresses above are the reliable identifier, not the header. Most of our European probes also resolve in reverse DNS under bot.howlops.com.

WAF compatibility

The versioned compatibility registry states the stable request identity and the limits of an allow rule. Use the current published source address together with the exact path you monitor. Do not create a zone-wide bypass, disable login protection, or treat a User-Agent as authentication. The registry is available as /prober-compatibility/v1.json.

robots.txt

When we crawl a site to discover things worth monitoring, we read your robots.txt and honour its Disallow and Crawl-delay directives. An uptime check is not a crawl — it is one address a person typed in, fetched on a fixed schedule — so it runs at the interval that person chose. If you want the checks to stop, the addresses above are the way, and we would rather you used it deliberately.

How much traffic to expect

One request per interval per region, and nothing else. A customer watching one URL every minute from four regions sends you 5 760 requests a day. If a site refuses us — a 429, a Retry-After, a block page — we slow that target down automatically and keep slowing it until it stops refusing, so telling us to back off works even without anyone reading a support ticket.

How to block it

Block the addresses above and the checks will stop reaching you. We would rather you did that deliberately than have a WAF do it silently, because a silent block looks like an outage to our customer: they get paged, they call you, and nothing was ever wrong. If you would prefer we stop entirely, write to us and we will take the target off our fleet.

What we will not do

We do not disguise our traffic. We do not rotate through residential addresses, forge browser fingerprints, or solve challenges meant to keep bots out. A monitor that works only by outsmarting your bot management is not measuring whether your site is up, and it would break on a schedule neither of us controls.

Who runs it

HowlOps, an uptime monitoring service. If this traffic is a problem for you, write to [email protected] and a person will read it. That address exists for site operators specifically, so it does not queue behind customer support, and we would rather hear from you than have you find out which of our addresses to block.