---
title: Probe locations & IP ranges
description: The 20 locations in 7 regions WatchFor checks from, the published IP ranges, and how to allowlist and cryptographically verify WatchForBot requests.
canonical: https://watchfor.io/docs/reference/probe-locations
---

# Probe locations & IP ranges

The 20 locations in 7 regions WatchFor checks from, the published IP ranges, and how to allowlist and cryptographically verify WatchForBot requests.

WatchFor runs checks from **20 locations across 7 world regions**. Checking
from many vantage points is what lets it tell a real outage from a local
network hiccup — and what makes latency numbers honest.

## Locations

| Region | Locations |
| --- | --- |
| Europe | Paris, Frankfurt, Vilnius, Madrid, Stockholm, London |
| North America | Ashburn, Columbus, Portland, Montreal, Querétaro |
| South America | São Paulo |
| Asia | Mumbai, Jakarta, Singapore, Tokyo |
| Middle East | Tel Aviv |
| Africa | Cape Town |
| Oceania | Sydney, Auckland |

Locations check over **IPv4 and IPv6** (all but one are dual-stack today).
The list grows over time — the
live list, with addresses and hostnames, is at
[watchfor.io/ip-ranges](/ip-ranges), and the location ids you need for the
API are returned by [`GET /v1/locations`](/docs/api/locations).

## Why multiple locations

- **Fewer false alarms** — a failure is [confirmed](/docs/alerting/incidents)
  from several locations before an incident opens and anyone is paged. A
  single failed location shows the monitor as **Degraded**, not **Down**.
- **Regional insight** — see when a problem affects one region but not others.
- **Honest latency** — response times reflect real-world distance, not one
  lucky data center.

Which locations a monitor uses, how many, and whether it runs from several at
once, is set per monitor and depends on your plan — see
[How checks run](/docs/monitors#how-checks-run) and [pricing](/pricing).

## Allowlisting WatchFor

If your service sits behind a firewall, WAF or allowlist, permit WatchFor's
probe addresses so checks aren't blocked. The full, current list — grouped by
region, with IPv4, IPv6 and hostnames — is at [watchfor.io/ip-ranges](/ip-ranges).

For automated allowlisting, pull one of the machine-readable endpoints on a
schedule instead of hard-coding addresses, so new locations are picked up
automatically:

- [`/ips.json`](/ips.json) — structured: `ipv4Prefix` / `ipv6Prefix` with
  `hostname`, `city` and `country` per entry
- [`/ipv4.txt`](/ipv4.txt) — plain IPv4 list, one per line
- [`/ipv6.txt`](/ipv6.txt) — plain IPv6 list, one per line

## Identifying and verifying WatchForBot

Every check that speaks HTTP identifies itself with one stable User-Agent:

```
Mozilla/5.0 (compatible; WatchForBot/1.0; +https://watchfor.io/bot)
```

A User-Agent can be spoofed, so there are three independent ways to verify a
request really came from WatchFor:

1. **Source IP** — requests come only from the published ranges above.
2. **Forward-confirmed reverse DNS** — every probe IP has a PTR record under
   `*.probe.watchfor.io`, named `<city>-<n>.<cc>.probe.watchfor.io` (for
   example `frankfurt-1.de.probe.watchfor.io`), and that hostname resolves
   back to the same IP. Reverse lookup, then forward lookup, then compare.
3. **Web Bot Auth request signatures** — HTTP(S) probe requests carry
   RFC 9421 HTTP message signatures with the `web-bot-auth` tag, signed with
   Ed25519:

   ```
   Signature-Agent: "https://watchfor.io"
   Signature-Input: sig1=("@authority" "signature-agent");created=…;expires=…;keyid="…";alg="ed25519";tag="web-bot-auth"
   Signature: sig1=:…base64 Ed25519 signature…:
   ```

   Fetch the public keys from
   `https://watchfor.io/.well-known/http-message-signatures-directory` and
   verify the signature — cryptographic proof that the request is ours.
   Bot-management platforms that support Web Bot Auth can allowlist WatchFor
   on this basis alone.

Signatures are sent by the HTTP-based probe types (website, API, MCP,
WebSocket, SSL/TLS certificate and grade, CDN, sitemap, favicon, Brotli, CMS,
domain and breach checks). Network-level checks (ping, TCP, UDP, DNS, MTR, NTP, SMTP,
IMAP, POP3, email round-trip, FTP, SFTP) carry no HTTP headers, so verify those by IP and reverse DNS.

What the bot does — and doesn't:

- It performs exactly the checks a customer configured, on the schedule they
  chose, from one location per check.
- It does **not** crawl your site, follow links or harvest content; it only
  touches the exact target of each monitor. Blocking it only breaks monitoring
  for the customer who configured it.

The [bot page](/bot) is the public reference for all of this.

## Using Cloudflare? Allowlist us in two minutes

WatchForBot is a **verified bot** in Cloudflare's
[bots directory](https://radar.cloudflare.com/bots/directory?q=watchfor) (Monitoring & Operations): Cloudflare
verifies our request signatures, and zones that allow verified bots let the
probes through with no rule at all. You need the rule below only if your zone
blocks or challenges verified bots — or that category — or if a challenge
still reaches your checks.

Cloudflare's bot protection (managed challenges, Bot Fight Mode, Super Bot
Fight Mode) can answer our probes with a JavaScript challenge — which a
monitoring request never solves. The result looks like a slow or failing site
in your dashboard even though real visitors are fine. One WAF rule fixes it:

1. In the Cloudflare dashboard open your zone → **Security → WAF → Custom
   rules** → **Create rule**.
2. Name it, for example, `Allow WatchFor monitoring`, and set the expression to
   match our User-Agent:

   ```
   (http.user_agent contains "WatchForBot")
   ```

3. Choose the action **Skip**, and tick at least *All managed challenges* and
   the bot-protection features you have enabled.
4. Deploy. Checks pass from the next run — nothing to restart on our side.

Worried about User-Agent spoofing? Add the probe IPs from
[`/ipv4.txt`](/ipv4.txt) and [`/ipv6.txt`](/ipv6.txt) to a Cloudflare
**IP list** and match `ip.src in $watchfor_probes` alongside the User-Agent.

The same idea applies to other CDNs and WAFs (Akamai, Fastly, AWS WAF):
exempt the `WatchForBot` User-Agent and/or our published IP ranges from bot
challenges and rate limits.

> **Info**
>
> Seeing failures only from WatchFor while your site is up? A firewall,
> rate limiter or bot challenge blocking probe IPs is the usual cause —
> allowlist the [published ranges](/ip-ranges) or add the Cloudflare rule
> above. The incident's [root-cause view](/docs/alerting/root-cause) shows the
> exact response each location received.

## Choosing IP version

Checks default to **IPv4**. Where your target supports it, switch a monitor to
**IPv6** in its settings — useful for verifying that your AAAA records and
IPv6 path actually work, not just that the IPv4 side does.

> **Also via API**
>
> `GET /v1/locations` lists every location with its id, city, country and
> region — pass those ids as `locations` when creating monitors. The
> `list_locations` MCP tool and `list-locations` A2A skill return the same.

---

Canonical page: https://watchfor.io/docs/reference/probe-locations · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt