How to bypass the Vercel firewall for your own monitoring
Updated September 2026
If your site is hosted on Vercel, its firewall can challenge Relvato's checks with a “Vercel Security Checkpoint” page and an HTTP 403 — while your visitors browse normally. Here's how to bypass the Vercel firewall for monitoring on a project you own, securely, with one rule.
What the block looks like
Your checks come back Skipped instead of passed or failed, with a note that the site returned HTTP 403 or that a bot-protection check didn't clear. Relvato stores a screenshot of exactly what its browser received, so you can confirm it yourself in the run's details.
That screenshot shows Vercel's interstitial: a spinner above “We're verifying your browser”, footed by “Vercel Security Checkpoint” and a request ID. When the challenge never completes you'll see “Failed to verify your browser” with a short code instead — the same block, one step further along.
Nothing is wrong with your site. Real visitors are unaffected; the challenge only meets automated requests.
Why Vercel challenges a monitor but not your visitors
Vercel's firewall scores every request for how much it looks like a real person. Relvato's browser checks lose on two counts at once: they run headless, and they run from a cloud provider's IP range rather than a home or mobile connection.
That's why the block is selective. Checks that fetch a URL over plain HTTP — broken links, SEO and metadata scans, mixed content — usually sail through, while the checks that drive a real browser (visual regression, Core Web Vitals, structure drift) are the ones challenged. If some of your checks pass and only the browser-driven ones fail, this is why.
It can also be intermittent. A single check may pass while a full “Run all checks” sweep gets challenged partway through, because a burst of browser page loads scores worse than one.
How to bypass the Vercel firewall (the one rule)
Every request Relvato makes to your site carries a stable header, X-Relvato-Token. Its value is unique to your site and derived from your site's signing secret — it never changes and can't be guessed, so it's safe to match on in a firewall rule. Copy it from Relvato under your site → Settings → “Behind Cloudflare or a firewall?”.
In the Vercel dashboard, open your project → Firewall → Custom Rules → New Rule. Add a condition where Request Header x-relvato-token equals the value you copied, then set the action to Bypass. Save and deploy — Vercel applies firewall changes in seconds.
Re-run the check. The checks that were skipped should now complete normally, and the run details will show real results instead of a checkpoint screenshot.
If you use Attack Challenge Mode
Attack Challenge Mode challenges every visitor, so it challenges Relvato too. It's designed as a temporary response to an active attack — if it has simply been left on, turning it off restores normal checking straight away.
If you need it on, add the custom rule above and re-run a check to confirm Relvato is let through. If the checkpoint still appears, Attack Challenge Mode is taking precedence over your rule, and you'll need to turn it off long enough for Relvato to capture a baseline.
Still blocked? Reduce the burst
If you can't add a firewall rule — a client's project, or a plan without custom rules — you can lower how much browser traffic Relvato sends at once.
Under your site → Settings, “Spread out checks” pauses between checks so “Run all” isn't one continuous stream of page loads. And in the visual regression check, monitoring one browser instead of several halves the page loads on the heaviest check.
Treat this as mitigation, not a guarantee: it lowers the odds of being challenged rather than removing the challenge. The firewall rule is the reliable fix.
Vercel firewall symptoms and fixes
| What you see | What it means | What to do |
|---|---|---|
| “We're verifying your browser” + Vercel Security Checkpoint | Vercel is challenging the request | Add the X-Relvato-Token Bypass rule |
| “Failed to verify your browser” + a code | The challenge never completed | Add the X-Relvato-Token Bypass rule |
| HTTP 403 on every check | Blocked at the edge, before your site | Add the rule; check Attack Challenge Mode |
| Only browser checks fail, HTTP checks pass | Bot scoring targets browser navigations | Add the rule, or reduce browsers and spacing |
Questions
Does bypassing the Vercel firewall make my site less secure?
No. The rule only lets through requests carrying your site's own secret token — a value derived from your signing secret that nobody else has. Every other request is still evaluated by your firewall exactly as before.
Why do only some of my checks fail?
Vercel's bot scoring targets requests that drive a real browser. Checks that fetch a URL over plain HTTP usually pass, while visual regression, Core Web Vitals and structure drift — which load pages in a browser — get challenged.
What does “Failed to verify your browser” mean?
It means the Vercel Security Checkpoint didn't complete, rather than just taking a moment to resolve. It's the same block as the “We're verifying your browser” page, one step further along — and the fix is the same.
Can I allowlist by IP address instead?
Not reliably. Relvato's browser checks run from a dynamic pool of addresses, so there's no stable IP to allow. The per-site header is the dependable way to identify Relvato's traffic.
I added the rule and it still fails.
Give it a moment to deploy, then re-run the check. Confirm the header value matches exactly with no extra whitespace, and check whether Attack Challenge Mode is on — it challenges all traffic and can take precedence over your rule.
Does this apply to Next.js sites not hosted on Vercel?
No — this is Vercel's own edge firewall. If you're on another host, or behind Cloudflare, Sucuri or Wordfence, the same X-Relvato-Token header works; see the general firewall allowlist doc.