Cloudflare Precursor Monitor Mode: Test Bot Detection Safely

Cloudflare announced Monitor mode for Precursor on 19 October 2026. Customers asked for a way to try Precursor, its session-based bot detection, without it changing bot scores, and this is Cloudflare’s answer. Under Security > Settings, the Precursor Status dropdown now has three values: Off, Monitor and Arm. In Monitor, Precursor collects signals, but its detections do not affect bot score or Challenge clearance. In Arm, they can affect both.

The same release split the Precursor Interstitial off from the mode. You now pick a sitewide default with Show Interstitial and add Interstitial Rules for particular requests. That split is where most of the risk sits, because the interstitial setting works in Monitor mode too. The rest of this guide covers what each setting does, how to roll Precursor out in Monitor, what to check before you Arm it, and the mistakes that cause broken API calls and surprise Challenges.

What Precursor does on your zone

Precursor is Cloudflare’s client-side bot detection that works across a whole session. A single Challenge checks a visitor once. Precursor keeps checking for as long as they browse. It went out to all customers on 13 July 2026. Cloudflare’s docs describe it as a loop:

• A script is injected into your pages.
• The script keeps collecting signals and running verification in the browser.
• Cloudflare evaluates the signals from each run.
• In Armed mode, the results can update the session state held in the cf_clearance cookie.
• The loop repeats for the whole session.

It is built to catch automation where each request looks legitimate on its own but the session as a whole shows non-human patterns. In Armed mode, Cloudflare says Precursor can re-validate Challenge clearance as behaviour changes, add session context to bot scores, and re-check visitors who have already passed a Challenge.

Precursor replaces JavaScript Detections (JSD). Both collect signals in the browser. Precursor keeps evaluating them for the whole session and keeps state per session. When either one contributes to a bot score, Cloudflare reports the source as JavaScript Fingerprinting.

What Monitor mode changes, and what it leaves alone

The docs define the three modes like this:

• Off: Precursor does not run.
• Monitor: Precursor collects signals. Its signals do not change bot score or Challenge clearance.
• Armed: Precursor signals can affect bot score and Challenge clearance.

Monitor mode keeps three things the same:

1. Bot scores. Precursor signals add nothing to bot score in Monitor. Any WAF custom rule that blocks or challenges on bot score keeps matching the same traffic it matched before.
2. Clearance. Precursor detections do not change Challenge clearance in Monitor. The interstitial is a separate setting that can still challenge visitors, covered below.
3. JSD. If you already use JavaScript Detections, Cloudflare keeps running it while you are in Monitor, so you lose no coverage during the test.

One thing does change: the Precursor script now runs on your pages and its detections show up in the zone’s Analytics. That is why you turn Monitor on. It lets you see what Precursor would do before you let it act.

Show Interstitial: the setting that can still challenge visitors

The announcement says Cloudflare separated the Precursor Interstitial from the mode. The interstitial now has settings of its own:

• Show Interstitial on: a visitor without a verified Precursor session gets an interstitial Challenge before they continue. This creates a valid session, but it may add friction.
• Show Interstitial off: session state is built in the background. Visitors are interrupted less, but Cloudflare cannot guarantee that every session is fully verified.
• Interstitial Rules override the sitewide default for specific requests, such as one path or one hostname.

The Precursor Interstitial is a lightweight Challenge. It sets up a verified Precursor session and grants Challenge clearance when the visitor has none. The interstitial settings are available in both Monitor and Armed modes, and you cannot reach them when Precursor is Off.

In practice, Monitor stops Precursor from changing scores and clearance. It does not stop the interstitial. With Show Interstitial on, a visitor with no verified session meets a Challenge in either mode. If you want a test with no visitor impact, keep Show Interstitial off while you are in Monitor.

Rolling out Precursor in Monitor mode, step by step

This is the order to follow when you turn Precursor on for the first time.

1. Write down your current bot score picture

You cannot tell what Precursor changed unless you know where you started. In the dashboard, open your zone and go to Security > Analytics > Traffic > Bot analysis. Note the bot score distribution and the match counts for any WAF rules that use bot score. On Pro plans and above, Security > Bots also groups traffic as Automated (score 1), Likely automated (2 through 29) and Likely human (30 through 99). Granular bot scores are only available to Enterprise customers who have bought Bot Management. On other plans, you only get the groupings.

From building Workers observability at Cloudflare, I would say the same for any change that touches every request: get the baseline before the change.

2. List every client that is not a browser

The docs warn that an interstitial can break two kinds of traffic:

• API endpoints called by clients that are not browsers, for example curl, mobile backends and server-to-server jobs.
• Browser API calls that do not send cookies.

List the hostnames and paths that serve this traffic, such as api.example.com or /api/*. You will need the list for Interstitial Rules.

3. Set Precursor to Monitor

1. In the Cloudflare dashboard, select your zone and go to Security > Settings.
2. Filter by Bot traffic or Precursor to find the Precursor card.
3. From the Status dropdown, select Monitor.

4. Choose the interstitial default and add rules

In the Precursor card, select the settings icon to set the sitewide interstitial default. The docs suggest one of two patterns for zones that serve both browser and API traffic:

• Off by default, on where it matters. Leave Show Interstitial off, then add an Interstitial Rule that requires it on sensitive browser paths such as /checkout, so every buyer has a valid session before they pay. This is the example Cloudflare gives in the announcement.
• On by default, off for APIs. Turn Show Interstitial on, then add Interstitial Rules that turn it off for your API hostnames or paths.

For a first test in Monitor, the first pattern is the safer choice. Most visitors see nothing, and any interstitial friction stays on the one path you picked.

Turning off the interstitial for an API endpoint does not turn off Precursor on browser pages. Those sessions are still evaluated under the mode you chose.

5. Make browser API calls send cookies

If front-end code calls an endpoint where the interstitial applies, the request must include cookies, or it has no verified session to show. Cloudflare’s docs give both common forms:

fetch("/api/search", {
  credentials: "include",
});

axios.get("/api/search", {
  withCredentials: true,
});

Search your codebase for fetch( and axios calls to your own API paths that leave this out:

grep -rn "fetch(\"/api" src/ | grep -v "credentials"

6. Check that non-browser clients still get through

From a machine with no cookies, call each API endpoint on your list and check that the response is the one your service normally sends:

curl -s -o /dev/null -w "%{http_code} %{content_type}\n" https://api.example.com/health
# expected: the same status and content type your API returned before the change

If you get an HTML page where you expected JSON, the interstitial is catching that path. Add an Interstitial Rule that turns it off there.

7. Watch Bot analysis while Monitor runs

Once Precursor is running on a zone, its detections appear under Security > Analytics > Traffic > Bot analysis, where the bot score distribution and WAF rule-match counts include them. Compare with the baseline from step 1. Look for Precursor flagging traffic you know is human, such as internal users, partner integrations or uptime checks, before those detections are allowed to change scores.

What happens when you switch from Monitor to Arm

graph TB A[Record bot score baseline] --> B[Set Precursor Status to Monitor] B --> C{Show Interstitial on?} C -->|yes| D[Add rules to turn it off for APIs] C -->|no| E[Require it on paths like checkout] D --> F{Non-browser clients still pass?} E --> F F -->|no| G[API clients get a Challenge page] G --> D F -->|yes| H{Bot score rules ready to Arm?} H -->|no| I[Review rules that act below 30] I --> H H -->|yes| J[Set Precursor Status to Arm] style G fill:#fee2e2,stroke:#fca5a5,color:#7f1d1d style J fill:#d1fae5,stroke:#6ee7b7,color:#065f46

Moving to Arm changes several things at once. Plan for each one.

Bot scores start to move

In Armed mode, Precursor signals can change bot score. Cloudflare warns that if you did not use JSD before, you may see more traffic with a bot score below 30. That is the line between Likely automated and Likely human. Any WAF custom rule that blocks or challenges below a score threshold will start catching sessions it used to let through. Expect more rule matches and decide whether they are what you want.

JSD switches off

In Armed mode, Cloudflare turns off JSD so the two features do not both run on the same traffic. Precursor covers the detections JSD used to cover, and Security Rules that rely on JSD still apply. If you read JSD-specific numbers in a dashboard or report, they will change when you Arm.

Clearance can be taken back mid-session

In Armed mode, Precursor works with the cf_clearance cookie. Effective clearance can be reduced or invalidated, extra Challenges can be triggered, and a visitor can be asked to verify again in the same session. A user who passed a Challenge an hour ago can be challenged again. Your support team should know this can happen.

Precursor and Challenges get stronger together

Cloudflare describes Challenges as checks at one point in time and Precursor as checks across the whole session. Once Armed, Precursor can decide when a Challenge should be required, re-check visitors after they pass one, and spot automation that only shows up over time.

Where Precursor rollouts break things

Treating Monitor as zero impact

Monitor protects bot score and clearance. It does not hide the interstitial. Fix: keep Show Interstitial off for the whole test, or limit it with an Interstitial Rule to one path you are ready to watch.

Turning Show Interstitial on for a zone that also serves an API

Cron jobs, mobile backends and partner integrations have no browser session, so they can be stopped by a Challenge they cannot complete. Fix: add Interstitial Rules that turn the interstitial off for API hostnames and paths, and test them with curl from a client with no cookies.

Browser fetch calls without cookies

A single-page app that calls fetch without credentials: "include" sends no session, so a protected endpoint sees an unverified visitor. Fix: add credentials: "include" to fetch, or withCredentials: true to axios, for every call to a path where the interstitial applies.

Expecting the API rule to turn Precursor off

An Interstitial Rule that turns off the interstitial for /api/* only controls the interstitial. Browser pages are still evaluated under your chosen mode. Fix: use the Status dropdown to control detection and Interstitial Rules to control the Challenge. They are separate controls.

Arming without reviewing bot score rules

Zones that never ran JSD may see more traffic below 30 after arming. A rule written for the old score spread can start blocking real customers. Fix: before you Arm, list every rule that uses bot score, and watch its match count in Bot analysis for the first hours after you switch.

Looking for the interstitial settings while Precursor is Off

The settings icon for the interstitial default is not available when Precursor is Off. Fix: choose Monitor first, then set the interstitial.

Reading a missing granular score as missing data

On plans without Enterprise Bot Management, you only see bot groupings and never the 1 to 99 score. Fix: compare the share of traffic in each grouping before and after the change.

A checklist before you Arm Precursor

1. Bot analysis baseline saved: score distribution and rule-match counts.
2. Precursor in Monitor for long enough to cover your normal weekly traffic pattern.
3. Show Interstitial default chosen on purpose, with Interstitial Rules for every API hostname or path.
4. Every browser call to a protected path sends cookies.
5. Non-browser clients tested from a machine with no cookies.
6. Every WAF rule that uses bot score reviewed for a rise in low scores.
7. Dashboards and reports that read JSD numbers updated, since JSD turns off in Armed mode.
8. Support told that visitors may be challenged again during a session.

Catching a Precursor change that breaks your Cloudflare app

When arming Precursor or adding an Interstitial Rule starts challenging an API client, the first sign is often a failing job or a drop in requests somewhere downstream. Polylane connects to Cloudflare, detects production issues like these, works out why they broke, and opens a pull request with the fix ready for your team’s normal review.

Running on Cloudflare? See how Polylane monitors Cloudflare in production.