# Belvador uptime probes: regions, IPs, user agent and opting out

> Where probes run, how they send requests, which addresses they refuse, the per-target rate cap and how a site owner asks us to stop.

Belvador's uptime probes are small machines that send the requests behind [uptime checks](https://belvador.dev/en/docs/uptime/quickstart). This page is for two readers: Belvador customers who need to allow the probes through a firewall, and site owners who see them in their logs.

## How to recognise a probe

Every HTTP request carries this User-Agent:

```text
BelvadorUptime/<version> (+https://belvador.dev/docs/uptime/probes)
```

The `+https://…` part links here. A probe sends `GET` or `HEAD` only, with no cookies and no `Authorization` header (Belvador refuses to store either); other headers come from the check's owner. TCP checks open a connection and close it without sending data.

## Regions and addresses

| Region | Location | IPv4 | IPv6 |
|---|---|---|---|
| Europe (`eu`) | Nuremberg (DE) — `nbg1` | `91.98.2.120` | `2a01:4f8:1c16:f108::/64` |
| North America (`us`) | Ashburn, VA (US) — `ash` | `178.156.225.93` | `2a01:4ff:f0:5b0a::/64` |
| Asia-Pacific (`ap`) | Singapore (SG) — `sin` | `5.223.53.122` | not published yet |

Each region runs its own probe; a check picks at least 2 of them. The address list is published here before a region starts checking and changes only when a probe machine is replaced. To allow the probes through a firewall, allow these addresses — or match the User-Agent if your provider supports that.

## Rate per target

Probes protect the sites they visit, across **all** Belvador workspaces together:

- At most one request every 10 seconds per region to the same target. A target is the host name and port as written in the check, not the IP address, so unrelated sites behind one CDN address do not slow each other down.
- A request that would break that cap waits at most 10 seconds before it starts (the wait is not part of its timing). If it would wait longer, it is not sent and the round counts as **unknown** for that region — never as down.
- Rounds that were missed while a probe restarted are not replayed later.
- Each check spreads its requests over the interval with a fixed offset, so many checks to one site do not arrive in the same second.

## What probes refuse

Probes connect only to public internet addresses. A check is refused when it is saved, and every request is judged again at the moment of connection, against every address the name resolves to:

- Private, loopback, link-local and carrier-grade NAT ranges (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, `127.0.0.0/8`, `169.254.0.0/16`, `100.64.0.0/10`, `fc00::/7`, `fe80::/10`, `::1`…), multicast, reserved and documentation ranges, and cloud metadata addresses such as `169.254.169.254`.
- IPv6 forms that hide an IPv4 address (`::ffff:…`, `64:ff9b::…`, `2002:…`) — judged by the IPv4 address inside.
- Belvador's own hosts.
- TCP ports 25, 465, 587 (mail submission), so a probe can never be used to send mail.
- URLs with a user name or password inside them.

The probe connects to the address it has just judged and sends the original host name for TLS and `Host`, so a DNS answer that changes between the check and the connection cannot redirect it. Each redirect hop is judged again from the start, at most 3 hops, and the check's own headers are not forwarded to another origin.

The same rules are enforced a second time by the probe machine's firewall, outside the probe program, and a third time by the operating system's sandbox. A name that resolves to a refused address gives the result **address blocked**, shown to the check's owner as a configuration problem.

## What a probe keeps

A probe reads at most 64 KB of a response into memory to check its conditions and keeps nothing after the round. When the check's owner has failure evidence turned on, the start of a failed response (at most 8 KB, secrets filtered) is sealed with their own node's key before it leaves the probe; Belvador cannot open it. More in [where uptime data lives](https://belvador.dev/en/docs/uptime/quickstart#6-where-uptime-data-lives).

## Opting out and reporting abuse

If you run a site and do not want Belvador probes to visit it, or you believe a probe is misbehaving, write to [hello@belvador.dev](mailto:hello@belvador.dev) with the host name, the time and, if you have it, the request line from your log. A host we block is refused for every workspace: their checks show **address blocked** and send no more requests. We do not need to know why.

To stop the probes yourself in the meantime, block the addresses above or answer the User-Agent with any error status — a probe never retries a round.