---
title: "Firewall allowlisting (Monitoring node IPs)"
description: "If your website is protected by a firewall or WAF, you may need to allowlist our monitoring nodes so we can reach your endpoint reliably."
---

## 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.

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

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

### Response

```json
{
  "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](https://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.