Allowlisting the YoPingMe probe

What to match on

Every check we run carries this user agent:

YoPingMe-Probe/v1.1.0 (+https://yoping.me/probe)

Match on the YoPingMe-Probe/ prefix, not the whole string. The version moves with each probe build, so a rule keyed to the full value stops matching the next time we ship one.

One thing worth knowing before you write the rule: the probe runs no JavaScript and stores no cookies. It reads only the first part of the response, far enough to read the status code and, on a keyword check, to look for your expected word. So a challenge is not a slower check for us. It is a failed one, and a failed check is what pages you at 3am.

Why we do not publish an IP list

Because it would be a list we cannot keep true. Our probe boxes get new addresses when they are rebuilt, and their reverse DNS resolves to*.compute.amazonaws.com rather than to us. A published list would go stale quietly, and a stale allowlist fails in the worst way: it locks out your own monitoring at the moment you need it, and nothing tells you it happened.

The user agent is the reliable handle. Match the header.

Cloudflare

The honest answer here depends on which product is doing the blocking, so check this first. Console paths are as of August 2026.

If it is Bot Fight Mode, a rule will not help

Bot Fight Mode is the free-plan bot protection, and Cloudflare's own documentation is explicit that it cannot be bypassed or skipped with WAF custom rules or Page Rules, because it runs outside the Ruleset Engine. Cloudflare also warns that it may challenge non-browser traffic, which is exactly what an uptime check is. If you have it on, the usual advice to add a skip rule will leave you believing you fixed something you did not.

Two things actually work:

• Turn it off, under Security Settings, filtered by Bot traffic, then Bot Fight Mode.
• Move to Super Bot Fight Mode, on Pro and above, which a custom rule can skip. Then follow the section below.

Everything else: a skip rule

Super Bot Fight Mode, Managed Rules, rate limiting rules, and your own custom rules can all be skipped for a matching request. Under Security rules, choose Create rule, then Custom rules, and build a rule with this expression:

starts_with(http.user_agent, "YoPingMe-Probe/")

In the visual builder that is field User Agent, operator starts with, valueYoPingMe-Probe/. Set the action to Skip, then tick the components you want skipped. The free plan allows 5 custom rules and every action except Log, so a skip rule fits there.

Skip narrowly. A user agent is a claim anyone can make, so exempting our checks from bot protection is reasonable, and waving them past your managed ruleset is not. Where it is practical, scope the rule to the path you actually monitor.

nginx and Apache

Most blocks at this layer come from an existing user-agent deny rule rather than a dedicated one, so the fix is an exemption ahead of it. In nginx, order matters among regex patterns inside a map: the first matching regex wins.

map $http_user_agent $blocked_ua {
    default            0;
    ~*YoPingMe-Probe/  0;   # uptime checks, keep above the deny patterns
    ~*(scrapy|masscan) 1;
}

In Apache 2.4, set a flag on the probe and let your deny rule test for it:

SetEnvIf User-Agent "^YoPingMe-Probe/" yp_probe=1

Any other WAF

The rule is the same shape everywhere, so it ports to AWS WAF, Fastly, Sucuri, or whatever sits in front of you: match requests whose User-Agent header begins with YoPingMe-Probe/, allow them or exempt them from bot protection, and scope that to the URL you monitor.

Still failing?

Check what the failing check actually returned. A 403, 429, or a challenge page in the check details points back here; a timeout or a 5xx is usually a real problem worth keeping the alert for. What the probe does and reads covers the rest, and support@yoping.me will look at a log line with you.

Not monitoring with us yet? The free plan watches 10 monitors, no card.