Analytics & WAF filtering

Two goals, one setup: keep warming traffic out of your analytics and let it through your bot protection. Both hinge on identifying the requests — which is easy, because they identify themselves.

Client-side analytics: nothing to do

The bot doesn't execute JavaScript, so Google Analytics, Plausible, Fathom, Piqo and every other script-based tracker never see warming requests at all.

Server-side analytics and logs

Filter on the WarmupRocks token in the user agent:

# Example: exclude in a log pipeline
awk '$0 !~ /WarmupRocks/' access.log

# Example: GoAccess
goaccess access.log --ignore-crawlers --unknowns-as-crawlers

Cloudflare Analytics counts warming requests as regular requests — but since most are edge HITs, they don't distort origin metrics. If you need a clean split, filter on the user agent in Logpush or the GraphQL Analytics API.

Letting warming through your WAF

Bot protection (Cloudflare Super Bot Fight Mode, Akamai Bot Manager, rate limiting) may challenge or block automated traffic — which would leave your cache cold. The clean solution is a shared secret header:

1. In your project settings, configure a custom header, e.g. x-warm-secret: <random-value>. It's sent with every warming request for that project.
2. Write an allow rule for requests carrying that header.

Cloudflare example

Security → WAF → Custom rules → Create rule:

Expression:  (http.request.headers["x-warm-secret"][0] eq "your-secret-value")
Action:      Skip  →  Super Bot Fight Mode, rate limiting rules

Nginx example

if ($http_x_warm_secret = "your-secret-value") {
    # bypass local rate limiting / bot checks
    set $limit_bypass 1;
}

Caution: don't bypass caching itself

The allow rule should skip bot checks, not caching. If your WAF rule accidentally sets warming requests to bypass cache, the warmed responses never get stored. After setting up rules, check the dashboard: cache status should go MISS → HIT between two runs.