Vercel Security Checkpoint on Your Own Site: Causes and Fixes.

When real visitors hit the Vercel Security Checkpoint page on your own site, the cause is almost always one of six things: a deploy script polling the production domain in a tight loop, an uptime monitor or health check hitting it too often, a load test pointed at production, a webhook sender retrying in bursts, a crawler or scraper scored as abusive, or Attack Mode or a WAF challenge rule left on. Confirm which in the project's Firewall tab (Overview, then Traffic grouped by Client IP Addresses and User Agents), stop the offending traffic, then decide whether you need a System Bypass rule, a short pause of system mitigations, or nothing. We ran into this on one of our own sites, and the fix was mostly about how we check deployments.

Vercel's platform-wide firewall inspects every request at Vercel's CDN, before your project's WAF rules and before your deployment. Its automatic DDoS mitigation runs on every plan and reacts to abnormal or suspicious request levels by denying with a 403 Forbidden or serving a challenge. The challenge is the Security Checkpoint screen: the browser must run JavaScript and submit a solution. Scripts, curl, uptime checkers and server-to-server calls cannot, so for them a challenge is a block.

The six causes we find most often.

Roughly in order of how often they turn out to be the answer.

• Deploy-wait loops on the production domain: a script or agent curls the custom domain every few seconds until the new build shows up, often several at once from one IP
• Uptime monitors and health checks: monitors hitting the homepage or an API route at short intervals, sometimes duplicated across two tools
• Load tests aimed at production: Vercel's load testing guide warns that such tests can be blocked by DDoS mitigation unless you add bypass rules first
• Webhook and integration bursts: a payment, CRM or form provider retrying a failing endpoint quickly, which looks like a flood from a narrow set of addresses
• Crawlers and scrapers: an SEO crawl, link checker or scraper run at full speed against your own site from one IP
• Attack Mode or a challenge rule left on: Attack Mode challenges all browser traffic by design, and a WAF custom rule with a challenge action blocks every non-browser client that matches it

How to verify what triggered the checkpoint.

The Firewall data tells you which layer acted and on whom. Three checks, in order.

The Firewall tab Overview. Open the project and select Firewall in the sidebar. The Overview shows a traffic graph (past hour by default, or 24 hours, or a live 10-minute window), Alerts for detected attacks, Rules that break traffic down by the rule that applied, and Events listing what the platform-wide firewall did. Expand an event to see the client it challenged or denied. If Rules shows your own custom rule or Attack Mode, your configuration did this, not the platform.

The Traffic page. Group by Client IP Addresses, then User Agents. A self-inflicted trigger usually looks like one IP (office, CI runner, cloud server) with a curl, python-requests, headless browser or monitoring user agent, sending far more requests than a human.

The CLI. vercel firewall overview prints the active configuration plus the last day of activity, and vercel firewall traffic list --since 1h shows requests by action with the top clients. The 24-hour window works on every team plan; longer lookbacks need Observability Plus.

Diagnose top to bottom.

Run these in order and stop at the first one that explains the block.

Symptom, cause and fix.

How to check a deployment without tripping the firewall.

Most self-inflicted checkpoints start with someone asking whether the new version is live yet, over and over. Ask the platform, not the domain.

• Run vercel inspect <deployment-url> --wait, which blocks until the deployment completes or the timeout (3 minutes by default) expires, without touching your site
• Or read GET /v13/deployments/{idOrUrl} from the REST API and wait for readyState to be READY
• If you must poll over HTTP, poll the generated vercel.app URL, not the custom domain, once every 30 seconds or slower. With Standard Deployment Protection, generated URLs require authentication, so the status check is usually better
• Run one loop, never two; agents and scripts that each spawn their own wait loop multiply the rate unnoticed
• Once it is READY, verify the custom domain with a single request, then stop

This now sits in the post-deploy section of our website migration checklist.

Pause system mitigations, Attack Mode and bypass rules.

Three Vercel features get confused during an incident. They do different things.

Pause System Mitigations turns off automatic DDoS protection and system-level filtering for one project for 24 hours, then resumes on its own. In the dashboard it is in the ellipsis menu at the top right of the project's Firewall tab; in the CLI it is vercel firewall system-mitigations pause, with resume to end it early. Vercel lists it for Pro and Enterprise. While paused you pay for all traffic served, including abuse that would have been blocked, so use it only when real customers are locked out at a moment that matters.

Attack Mode is the opposite lever. It challenges all browser visitors while letting verified bots (search crawlers, known webhook providers) and your own Functions and Cron Jobs through. It is free on all plans and meant for a targeted attack. It never fixes an unwanted checkpoint, so check it was not left on.

System Bypass rules are the permanent, narrow option. In Firewall, choose Add New, then System Bypass, and enter an IP or CIDR range plus a domain (or * for all of the project's domains). Vercel documents 25 rules per project on Pro and 100 on Enterprise; Hobby has none. A System Bypass does not get traffic past your own WAF custom rules; that takes a custom rule with a bypass action.

What is normal and what is a red flag.

Some challenge activity is expected. The platform challenges or blocks traffic it scores as illegitimate on every site, and Vercel does not charge for traffic it blocks.

A browser that passes the checkpoint once gets a challenge session Vercel documents as valid for 1 hour. If the same person is challenged on every page load, look at a WAF rule or a browser setting that drops the session.

Vercel raises a DDoS attack alert when mitigation detects malicious traffic above 100,000 requests over a 10-minute period. Your own scripts rarely reach that, so no alert does not mean no mitigation. You can subscribe to the Attack Detected Firewall Event with a webhook or the Vercel app for Slack.

Red flags: the checkpoint appears on several networks at once, your uptime monitor goes red while the site loads in your browser, webhook deliveries fail, or conversions drop to zero. Ad clicks landing on a checkpoint never fire a pixel, which is why our conversion tracking audit checklist includes a live landing page check. Server-to-server tracking such as an affiliate postback fails silently when the receiving endpoint is challenged.

Legitimate traffic that trips it.

Uptime monitors, health checks, SEO crawlers, webhook senders and load tests are legitimate, and all of them look like automation because they are. Vercel keeps a verified bots directory that includes search crawlers, monitoring services and webhook providers; verified bots pass Attack Mode and are excluded from the bot protection ruleset. The docs do not say verification exempts them from automatic DDoS mitigation, so use a sensible interval plus a System Bypass for any fixed-IP source you depend on.

If Search Console coverage shifts after an incident, our piece on pages indexed but getting no impressions covers telling a crawl problem from a ranking one.