The SutramX-Monitor Bot

SutramX-Monitor is the uptime checker operated by SutramX. It sends scheduled requests to endpoints that our customers have explicitly configured for monitoring — almost always their own websites and APIs. If you are seeing it in your access logs, someone with access to that service asked us to watch it.

1. How to identify us

Every uptime check we make carries this exact user agent string:

Mozilla/5.0 (compatible; SutramX-Monitor/1.0; +https://sutramx.com/bot)

Matching on the substring SutramX-Monitor is the most durable rule — it survives version bumps. We never disguise our checker as a browser, and we never rotate this string to evade filters.

Browser checks (scripted multi-step tests) run a real Chromium browser, so they send Chromium's own user agent with this token appended:

SutramX-Browser/1.0 (+https://sutramx.com/bot)

Match on SutramX-Browser for those. Bot protection such as Cloudflare Bot Fight Mode often blocks automated browsers from cloud servers outright, so browser checks usually need an allow rule even when plain uptime checks get through.

Signed requests (Web Bot Auth)

Uptime and browser checks are also signed with Web Bot Auth (HTTP Message Signatures, RFC 9421), so a firewall can verify cryptographically that a request really comes from SutramX — a user agent can be copied, a signature cannot. Each request carries Signature-Agent: "https://api.sutramx.com" with Signature-Input and Signature headers covering the host, and our public key is published at api.sutramx.com/.well-known/http-message-signatures-directory. Signatures are valid for one minute and bound to the host they were made for.

2. Where we check from

This list is the authoritative source for our checker addresses and is updated whenever we add, move or retire a location. SutramX checks from 3 regions (Frankfurt, AZ (Arizona, USA) and Mumbai); a location is listed here once its address is published, so the table may list fewer locations than that. If you allowlist by IP, also allowlist the SutramX-Monitor user agent where your firewall supports it, so checks from a new or moved location keep working, and re-check this list (or fetch the plain-text copy from automation):

A plain-text copy suitable for scripts is available at sutramx.com/bot/ips.txt. Some addresses, such as Arizona's, can change at short notice, which is another reason to allowlist the user agent as well. Every change is listed under address changes below.

If a region is unavailable

If a region is unavailable, for example while a checker moves to a new address, monitors keep checking from the remaining regions. A real outage is still reported: it is confirmed when every remaining region sees the failure on consecutive checks, and the alert and incident timeline say it was confirmed with reduced coverage. Recovery needs a majority of the regions that are online.

Address changes

Every change to a published checker address, newest first. We post a change here when it takes effect, and in the changelog.

• October 3, 2026 (fra1): Built-in checker moved from the USA to Frankfurt, Germany: 52.5.130.219 replaced by 63.180.157.22. Remove the old address from allowlists.
• October 3, 2026 (usa-az-probe): Arizona, USA checker published at 46.202.196.109.
• October 3, 2026 (New York): New York location retired; its monitors moved to Frankfurt automatically.

3. How we behave

• We only request what we were told to. We fetch the exact URL configured on a monitor. We do not crawl, follow links, or discover new pages.
• Predictable, low volume. One scheduled request per monitor per interval from each region assigned to it, with the interval chosen by the customer between every 15 seconds (Pro) and every 15 minutes. When a check fails, it is retried once from the same region about two seconds later. We do not burst.
• We identify honestly. No browser impersonation, no fingerprint spoofing, no proxy rotation to bypass blocks.
• We respect refusals. If you block us, we report the block to the monitor's owner rather than attempting to work around it.

4. Allowlisting instructions

Allowlisting by user agent is usually simplest; allowlisting by IP is stricter and cannot be spoofed by a third party. If your endpoint is sensitive, prefer IP, or combine both.

Cloudflare

What works depends on your Cloudflare plan and which bot protection is on. SutramX has applied to Cloudflare's Verified Bots program and signs its requests (see signed requests); until Cloudflare recognises SutramX as a verified bot, use one of the options below.

Free plan with Bot Fight Mode on. Bot Fight Mode cannot be bypassed with WAF custom rules, a Skip action or Page Rules. You have two options:

• Add an IP Access Rule with the action Allow for each address in /bot/ips.txt, under Security → WAF → Tools → IP Access Rules. Bot Fight Mode does not challenge a request that an IP Access Rule has already allowed. Update the rules when an address changes (see address changes).
• Or turn Bot Fight Mode off under Security → Bots.

Pro plan and above (Super Bot Fight Mode). Go to Security → WAF → Custom rules, create a rule with the action Skip, and under WAF components to skip select All Super Bot Fight Mode rules, with an expression matching our addresses:

(ip.src in {63.180.157.22 46.202.196.109})

Managed rules, rate limiting and your own custom rules (any plan). A Skip custom rule can also skip the remaining custom rules, managed rules and rate limiting rules. Place it first. This expression only affects those WAF rules, not Bot Fight Mode:

(ip.src in {63.180.157.22 46.202.196.109}) or (http.user_agent contains "SutramX-Monitor") or (http.user_agent contains "SutramX-Browser")

The user agent part keeps checks working if an address changes, but anyone can send that user agent; drop it if you only want to trust our addresses.

Vercel

Under Project → Firewall, add a rule matching the IP addresses above with the action Allow, and make sure it is ordered above any Attack Challenge or bot rules. Attack Challenge Mode blocks datacenter traffic by default and will reject checks until the allow rule exists.

AWS WAF

Create an IP set containing the addresses above, then add a rule referencing it with the action Allow and a priority lower (numerically) than your bot-control or rate-based rules.

nginx

allow 63.180.157.22;
allow 46.202.196.109;

Apache

<RequireAny>
  Require ip 63.180.157.22
  Require ip 46.202.196.109
</RequireAny>

WordPress security plugins

Wordfence, Sucuri, and similar plugins maintain their own allowlists. Add the IPs above to the plugin's allowlist — and, if it offers rate limiting, exempt them there too, since frequent checks from 3 regions can otherwise trip a throttle.

A note on secret headers

If you would rather not allowlist by IP or user agent, every SutramX monitor can send custom request headers. Configure a header with a secret value on your monitor, then allowlist requests carrying that header in your firewall. This is the most precise option, and it keeps working if our addresses ever change.

5. Blocking us

If you do not want SutramX-Monitor requesting your service, block the user agent or the IP ranges above and we will stop reaching you — the monitor's owner will see the checks fail. If you believe someone is monitoring a service they do not own, or you need us to stop for any other reason, contact abuse@sutramx.com with the target URL and we will investigate.

6. Contact

Questions about this bot: support@sutramx.com. Security concerns: security@sutramx.com.