Firewall allowlisting (Monitoring node IPs)

Dashboard (UI)

You can view the current IP allowlist in the dashboard sidebar under “IP Addresses”.

API (Automation)

To fetch the current list programmatically, use the authenticated endpoint:

• GET /api/ips

Authentication

Use an API token generated in the dashboard.

BASE_URL="https://uptimeify.io"
TOKEN="wsm_<your-api-token>"

curl -H "Authorization: Bearer $TOKEN" "$BASE_URL/api/ips"

Response

{
  "ipv4": ["203.0.113.10"],
  "ipv6": ["2001:db8::10"],
  "locations": {
    "de-nbg": ["203.0.113.10"]
  },
  "updated_at": "2026-01-01T00:00:00.000Z",
  "documentation": "https://uptimeify.io/docs/integrations/firewall"
}

Notes:

• The IP list can change over time. Don’t hard-code it permanently.
• Prefer periodic syncing on your side (e.g. via a scheduled job).

How to recognise our checks in your logs

Besides the source IP, every check identifies itself in two ways. Either is enough to allowlist on, and both are stable, use them if you would rather not track a changing IP list.

User-Agent

Simple checks (HTTP, SSL, redirects) send:

SiteMonitorBot/1.0 (+https://uptimeify.io)

Browser-based checks (screenshots and Playwright monitors) send a normal Chrome User-Agent with that token appended:

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)

The browser prefix is deliberate. A Playwright monitor walks a real user journey, a login, a checkout, and many WAFs block a bare bot User-Agent outright. That would make us report an outage your visitors are not experiencing. So we keep the browser shape and add our name to it, rather than pretending to be nothing but a bot.

If you match on User-Agent, match on the substring SiteMonitorBot, never on the full string, which carries a Chrome version that changes with every browser update.

Request header

Every check also sends:

X-Uptimeify-Monitor: 1

This is the more reliable of the two: a CDN or reverse proxy can rewrite a User-Agent, and bot mitigation sometimes strips it. The header is a constant and never contains a monitor, customer or account identifier, nothing about your account is exposed to anyone reading your access log.

Rate

Checks arrive at the interval you configured, from each location you enabled. They do not crawl: a simple check is one request, a Playwright monitor is exactly the journey your script describes.

Which bot is this, and how do I stop it

Allowlisting is one direction. If you would rather block us, or you are looking at a client that is not a monitoring check at all, the full account is on uptimeify.io/robot: every automated client we operate, what each one requests and how often, the addresses it comes from, and ready-made rules for Cloudflare, nginx and Apache.

Two clients besides SiteMonitorBot appear there. UptimeifyStatusBot reads the public status pages other companies publish about themselves. UptimeifyToolsBot fetches an address someone entered into one of our free tools or passed to our MCP server, once, with no schedule behind it.

None of the three reads robots.txt. A monitoring check is ordered by the site owner, so a Disallow written by a third party would switch off a check somebody on your own team relies on. Blocking works at your CDN, WAF or web server.