Allowlisting VisualRunner Traffic¶

If your site sits behind a firewall, WAF, or bot-protection service (Cloudflare, AWS WAF, Akamai, Imperva, and similar), that protection can block VisualRunner's monitoring requests and cause false failures — scans that find nothing, captures that render an error page, uptime checks that report "down", or an environment test that won't pass. Allowlisting VisualRunner's traffic fixes this.

This is you explicitly authorizing VisualRunner to monitor a site you control. VisualRunner only ever visits a site after someone has added it to their own VisualRunner account and configured a scan, monitor, capture, or uptime check against it. It does not crawl the open web.

What to allowlist¶

Allowlist by source IP address. VisualRunner monitoring traffic for your site — discovery scans, screenshot captures, scheduled monitors, uptime checks, and the environment connectivity test — comes from a single outbound IP address:

157.230.2.191

Private Runner exception. If an environment's Capture delivery is set to a Private Runner, its screenshot captures and screenshot Monitors run from inside your own network and do not use this IP — nothing to allowlist for those. Uptime checks, discovery scans, and the environment connectivity test still come from 157.230.2.191 regardless, so you still need this IP allowlisted if you run any of those against a protected site.

Interim notice — this address is current, not permanent. VisualRunner is moving to a dedicated, fixed egress address. Until that lands, 157.230.2.191 is stable (it does not change on its own) but is not guaranteed forever. Contact us before you rely on it (see below) so we can:

confirm it is still the correct address for your account, and

add you to the notification list — we will email you at least 14 days before this address ever changes.

Do not allowlist by User-Agent alone — see Identifying VisualRunner.

Contact us first¶

Email support@visualrunner.com (or your account contact) before allowlisting, with:

your VisualRunner account / workspace name, and
the domain(s) you are about to allowlist.

We reply with the current egress IP to allowlist and add you to the change-notice list. This is also how you reach us about unexpected traffic or to pause monitoring of a property.

How to allowlist (by platform)¶

In every case you are adding an IP allow rule that runs before your bot-protection rules, so VisualRunner's requests skip the challenge/block.

Platform	Where
Cloudflare	See Cloudflare below — an IP Access Rule (simplest) or a Custom Rule with the Skip action. No Enterprise plan or Account-level WAF add-on needed.
AWS WAF	Create an IP set containing `157.230.2.191/32`, add a rule referencing it with action Allow, and place that rule above your managed/bot rules in priority order.
Akamai	Add the IP to an allowlist / trusted IP network list and reference it in a Bot Manager or WAF exception for the affected paths.
Imperva / other	Add `157.230.2.191` as an allowlisted / whitelisted source IP that bypasses bot mitigation and rate limiting.
Generic firewall	Allow inbound HTTPS (443) from `157.230.2.191` to the hostnames VisualRunner monitors.

If your site uses HTTP Basic Auth or an IP-restricted staging environment, add the same IP there too, or configure per-environment credentials in VisualRunner (Project → Environment → authentication).

Cloudflare¶

You do not need Cloudflare's Enterprise plan, and you do not need the Account-level WAF add-on, to allow VisualRunner. Account-level WAF is a separate Enterprise capability that is unnecessary for this. Both options below work on Cloudflare's standard plans, subject to Cloudflare's own product limits (for example, how many custom rules your plan includes).

Cloudflare renames its dashboard menus from time to time. The paths below read as Security → WAF / Security rules → …; if a label doesn't match exactly, look for the nearest equivalent under your zone's Security area — the exact location varies slightly by dashboard version and plan.

Recommended — Allow the VisualRunner IP (IP Access Rule)¶

The simplest way to have Cloudflare trust VisualRunner traffic is a single IP Access Rule.

Security → WAF → Tools → IP Access Rules (some dashboards: Security → Security rules → IP Access Rules)

Field	Value
IP	`157.230.2.191`
Action	Allow
Zone	The site(s) you monitor with VisualRunner

An Allow IP Access Rule exempts that one IP from IP-based blocks, most managed mitigations, and rate limiting for the zone, while every protection stays fully in place for all other visitors. For the common "just let VisualRunner in" case this is all you need. IP Access Rules are available across Cloudflare plans, subject to Cloudflare's current product limits.

Advanced — Custom WAF rule (Skip)¶

If you want fine-grained control over exactly what authorized VisualRunner traffic bypasses, create a zone-level Custom Rule instead.

Security → WAF → Custom rules → Create rule

Expression: (ip.src eq 157.230.2.191)
Action: Skip
Skip components: select the security features that should be skipped for authorized VisualRunner traffic — depending on your configuration and plan this typically means remaining custom rules, rate limiting rules, and the managed rules / WAF managed ruleset. Choose only what applies to you.

Bot Fight Mode caveat. Cloudflare has two similarly-named bot features that behave differently with a Skip rule:

Super Bot Fight Mode (Pro plan and above) can be added to a Custom Rule's Skip list, so authorized VisualRunner traffic bypasses it.
Bot Fight Mode (the free-tier on/off toggle) has different limitations and is not something a normal Custom Rule can reliably skip. If you rely on Bot Fight Mode and still see VisualRunner blocked, use the IP Access Rule above with action Allow — that is the dependable way to trust the VisualRunner IP in that case.

Whatever rule type you use, match on the source IP — it is the reliable signal (see Identifying VisualRunner traffic).

Verification header (instead of, or as well as, the IP)¶

Each environment can have its own secret, which VisualRunner sends as a header on its requests to your site:

X-VisualRunner-Verify: vr_<your-environment-secret>

Your WAF rule matches the header instead of our IP, so you don't have to allowlist an IP at all. Or match both the IP and the header, so traffic is trusted only when it comes from our IP and carries your secret.

Set it up:

In VisualRunner, open Project → Environments. On the environment's card, next to Firewall verification header, click Generate.
Copy the secret. It is shown only once. If you lose it, click Regenerate and update your rule.
In Cloudflare, go to Security → WAF → Custom rules → Create rule:
Expression: (http.request.headers["x-visualrunner-verify"][0] eq "vr_<your-secret>")
Action: Skip. Skip the remaining custom rules, managed rules, rate limiting and Super Bot Fight Mode.
Place the rule first.
Run the environment's connectivity test to confirm it passes.

Other WAFs (AWS WAF, Akamai, Imperva) work the same way: a rule that matches the header value and bypasses bot protection.

How the secret is protected:

It is sent only over https, and only to the environment's own domain and its subdomains (for https://www.example.com, that's example.com and *.example.com). Third-party scripts, analytics and CDNs on your page never receive it, and neither does a redirect to another domain.
It is stored encrypted, never shown again after you copy it, and never written to logs.
Regenerating it stops the old secret working immediately.

Limits:

Cloudflare's free-plan Bot Fight Mode can't be skipped by a custom rule. Use Super Bot Fight Mode (Pro and above), turn Bot Fight Mode off, or use the IP Access Rule above. I'm Under Attack mode also overrides custom rules.
An environment whose base URL is http:// never sends the header.
Captures delivered by a Private Runner don't send it.

Recommended approaches, in order of increasing strictness:

Stable VisualRunner egress IP: the simplest option, suitable for almost everyone.
Verification header only: when you'd rather not allowlist an IP.
IP + verification header: trust traffic only when both match.

Identifying VisualRunner traffic¶

Source IP is the reliable signal. The IP above is what you should match on.

User-Agent is informational only. Depending on the activity you will see one of these — do not build access rules around them:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36
Localization-QA-Uptime/1.0

Screenshot captures and the environment test use a standard Chromium User-Agent because they render the page in a real browser. The browser-like scanner User-Agent is deliberate — it exists so ordinary "block non-browser clients" WAF rules don't cause false monitoring failures. It is not a disguise; the traffic all originates from the published IP.

You can also match a per-environment secret header (X-VisualRunner-Verify) instead of, or as well as, the source IP. See Verification header.

Draft email to send to your IT / security team¶

Copy, fill in the bracketed parts, and forward:

Subject: Allowlist VisualRunner monitoring traffic for [yourdomain.com]

Hi [team],

We use VisualRunner (visualrunner.com) to monitor [yourdomain.com] for visual changes, content changes, and uptime. Our WAF / bot protection is currently blocking some of its checks, which produces false alerts.

Please add an allow / skip rule for this source IP so authorized VisualRunner monitoring traffic is exempt from the applicable bot-mitigation and rate-limiting checks:

157.230.2.191

Scope it to the hostname(s): [list the domains VisualRunner monitors]

Notes:

This is a single outbound IP for VisualRunner's monitoring of our account (discovery scans, screenshot captures, scheduled monitors, uptime checks).
Match on the IP address, not User-Agent — some of the traffic uses a normal browser User-Agent because it renders pages in a real browser.
The rule should run before the bot-protection / managed rules so the allow takes effect.
VisualRunner has told us they will email us at least 14 days before this IP ever changes; I'll forward any such notice.

Thanks, [name]

When the egress IP changes¶

VisualRunner will email everyone on the change-notice list at least 14 days ahead with the new address and a cutover date. When you get that notice:

Add the new IP alongside the old one in your allow rule.
Leave both in place until the cutover date has passed.
Remove the old IP.