How Detectors Work

Overview

Edge runs a stack of detectors across three cron tiers. Fast detectors run every minute (acute traffic spikes, credential-stuffing fingerprints, per-path anomalies), slow detectors run hourly (baseline-comparison detectors, bot analysis, probe/scanner surveillance), and certificate checks run daily. Each queries Workers Analytics Engine or D1 for patterns and compares against baselines or thresholds.

Fast detectors (every minute)

ASN Spike

Catches a single ASN suddenly sending many times more traffic than its own recent average. Compares a 5-minute window against a 60-minute baseline.

When it trips: current rate exceeds the baseline by the configured multiplier (default 5x) AND total requests exceed a floor (default 10,000).

499 Rate

The scraper signature detector. A 499 means the client closed the connection before the edge finished responding. Scrapers on tight timeouts do this constantly.

When it trips: per-ASN 499 ratio exceeds the threshold (default 20%) AND total requests exceed a floor (default 1,000).

Cache Bypass

Catches ASNs whose request mix deviates from the site's healthy cache baseline. Attackers hammering uncacheable URLs shift their mix to mostly miss/dynamic.

When it trips: per-ASN bypass ratio exceeds the baseline by the configured multiplier (default 3x) AND total requests exceed a floor (default 5,000).

User-Agent Rotation

Catches bots cycling through many fake user-agent strings. A real human population from one ISP presents 3-6 UA families. 15+ is the bot signature.

When it trips: per-ASN distinct UA family count exceeds the threshold (default 15) AND total requests exceed a floor (default 5,000).

Hourly detectors

Slow Burn

Catches gradual escalation that no fast detector fires on. Compares a 7-day rolling window against a 28-day baseline on three axes: total volume, 499 ratio, and cache hit ratio.

When it trips: any axis exceeds its deviation threshold AND weekly volume exceeds a floor (default 100,000). Severity scales: 1 axis = info, 2 = warning, 3 = critical.

Bot Score

Catches ASNs sending predominantly automated traffic as scored by Cloudflare Bot Management, whose bot traffic is actually hitting origin (bypassing cache). The BotScore field (1-99) is available in SFCC eCDN Logpush — scores below 30 indicate likely bots.

When it trips (v2, from 2026-04-21): three conditions must all hold:

1. The ASN's ratio of bot-scored traffic exceeds bot_ratio_threshold (default 50%)
2. Total requests from the ASN exceed min_requests (default 1,000)
3. Of the bot traffic, the share bypassing cache exceeds bot_bypass_ratio_threshold (default 30%)

Why the cache-bypass qualifier exists: without it, the detector fired indiscriminately on any bot-dominated ASN and collapsed three operationally distinct patterns into the same alert. Googlebot indexing (99% cache hit) and SFCC-integrated SaaS vendors (99% cache hit) looked identical to credential stuffing via AWS IPs (100% cache bypass). The first two are benign — bots served from cache cost the origin nothing. The third is real abuse. The qualifier ensures only the actionable pattern trips.

What to check when this fires:

• bot_bypass_ratio_pct in Rule details — above 70% is near-certain scraping
• Top path breakdown on AsnDetail — dynamic endpoints (/on/demandware.store/*, /Account-*) are the concerning shape
• Unique IP count on the ASN — many IPs at low per-IP volume = coordinated fanout, few IPs at high volume = single actor

Preferred mitigation: Cloudflare WAF rule targeting this ASN, scoped to non-static paths. Bot Fight Mode is available but blunter.

TLS Weak Protocol

Detects traffic using deprecated TLS 1.0/1.1 or no encryption. May indicate misconfigured scrapers, legacy integrations, or compliance risk (PCI DSS 4.0 requires TLS 1.2+).

When it trips: the ratio of weak-protocol traffic exceeds the threshold (default 1%) AND total requests exceed a floor (default 1,000). Severity: 1-5% info, 5-10% warning, 10%+ critical.

Path Entropy

Catches systematic catalogue crawling by measuring how evenly an ASN distributes requests across URL paths. Legitimate users hit popular pages heavily (low entropy); catalogue walkers hit every path evenly (high entropy).

When it trips: normalised Shannon entropy exceeds the threshold (default 0.85) AND the ASN has enough distinct paths (default 20) and requests (default 5,000). Critical when entropy > 0.95 AND distinct paths > 3x the floor.

Challenge Solving

Detects post-mitigation evasion where attackers upgrade tooling to solve WAF challenges after being blocked. Compares the challenge solve rate in a 2-hour current window against a 24-hour baseline.

When it trips: the solve rate has increased by the configured percentage (default 50%) AND the ASN had significant challenge activity in the baseline (default 100+ challenged requests). Warning at 50-200% increase, critical above 200%.

Operation Fingerprint

Identifies the same scraping operation appearing from a new network. Builds a behaviour profile per ASN (path distribution, UA mix, status code distribution) and compares it against known-bad profiles.

When it trips: an ASN's behaviour hash matches a known-bad profile with confidence above the threshold (default 0.7) AND requests exceed the floor (default 5,000). Supports monitor mode (log only) and alert mode.

Every-minute detector (fanout)

IP Fanout

Catches attacks where many distinct IPs from the same ASN hit one path each doing modest volume — the pattern ASN Spike misses because aggregate ASN volume isn't anomalous, and IP Spike misses because no single IP stands out. The canonical case is a credential-stuffing operation fanning out across cloud provider IPs.

How it works: queries the edge_request_ips dataset over the last 30 minutes, grouped by (ASN, country, path). Trips when the distinct-IP count on a single path from one ASN exceeds the per-type threshold AND request volume exceeds the per-type floor.

Per-ASN-type thresholds (default):

ASN type	Min distinct IPs	Min requests
cloud (AWS/GCP/Azure/CF)	5	50
vpn-proxy	5	50
transit	20	500
isp (residential)	80	2,000
other (unknown)	30	500

Cloud and VPN/proxy fire at tiny counts because legitimate cloud traffic to a retail storefront rarely originates from many distinct IPs — real backends route through a handful of egress addresses. Residential ISPs have enormous natural IP diversity (CGNAT, DHCP) so they only trip at much higher counts.

Severity: warning at the threshold, critical at 2× threshold.

Dimension key: asn:<asn>|cc:<country>|path:<path>.

Method Shift

Catches the credential-stuffing / enumeration signature: a surge of POSTs from one ASN on one path where a meaningful share of those POSTs are failing with 4xx. Real users mostly succeed on login; attackers mostly fail.

How it works: queries the primary edge_requests dataset filtered to blob13 = 'POST' over the last 10 minutes, grouped by (ASN, country, path, status_class). Aggregates per (ASN, country, path) to compute the 4xx ratio, trips when both the POST count and the 4xx ratio exceed the per-type floor.

Per-ASN-type thresholds (default):

ASN type	Min POSTs	Min 4xx ratio
cloud	20	20%
vpn-proxy	20	20%
transit	100	30%
isp (residential)	500	50%
other (unknown)	50	30%

Cloud and VPN/proxy fire early because legitimate automated POSTs to a retail login / password-reset path are rare. Residential ISPs produce real POSTs from real users, so they only trip when 4xx ratio is genuinely high AND volume is significant.

Severity: warning at the threshold, critical at 2× threshold (capped at 95% to handle ISP thresholds where 2× would exceed 100%).

Why the 4xx qualifier matters: without it, a popular login endpoint would trip on every cron tick just from normal POST traffic. The 4xx ratio is what separates normal login traffic (mostly 2xx/3xx) from credential abuse (overwhelmingly 4xx).

Pairs with IP Fanout: a coordinated credential-stuffing operation fires both detectors on the same (ASN, path). Two detectors agreeing is high-confidence; one without the other may be a tuning issue worth investigating.

Dimension key: asn:<asn>|cc:<country>|path:<path>|method:<method>.

Origin Latency Spike

Catches origin-side regressions — DB locks, slow dependencies, bad deploys — before they cascade into site-down. Different audience from the anti-scrape detectors: this wakes the dev team, not the WAF operator.

How it works: queries the primary edge_requests dataset over the current window (default 10 min) and baseline window (default 60 min), computing a weighted average origin response time per path. Cache hits are excluded (blob6 != 'hit') so the number reflects requests that actually touched origin. Trips when the current-window average exceeds the baseline by the multiplier AND the absolute average is above a floor AND the non-cached request count is high enough to be statistically meaningful.

Defaults:

Parameter	Value	Why
window_minutes	10	Short enough to catch fast regressions, long enough to smooth outliers
baseline_minutes	60	Rolling comparison against recent normal
multiplier	2	2× slowdown is a meaningful regression
min_origin_ms	1000	Under 1s is noise even at high ratios
min_requests	100	Need enough data for the average to be stable
critical_origin_ms	5000	Above 5s the path is effectively down

Severity: warning when ratio crosses the multiplier, critical when either (a) ratio crosses 2× the multiplier or (b) absolute latency exceeds critical_origin_ms.

Data shape caveat: AE double3 is the sum of origin_ms per bucket, not individual request times. We compute a weighted average, not P95. Good enough for trend detection; for tail latency check the SFCC logs directly.

Ships enabled by default — unlike the anti-scrape detectors, latency regressions are low-false-positive and operators want them from day one. A path averaging 5 seconds to origin is never OK regardless of whether the multiplier looks right.

Dimension key: path:<path>.

Probe / Scanner

Catches reconnaissance activity that every volume-based detector misses. Scanners probe dozens of non-existent paths — wp-login.php, /.env, /backup.zip, /phpmyadmin, /.git/config, /wp-content/upgrade/alfacgiapi — and move on. Each probe is tiny (often under 50 requests per week across your whole tenant), so no volume threshold would ever trip. But the structural signature — many distinct probe paths × failed status × one ASN — is diagnostic.

How it works: a separate AE dataset (edge_probe_paths) captures only 4xx and 5xx records, with per-request classification into one of seven families:

Family	What it catches
wordpress	wp-login, wp-admin, wp-content, wp-includes, wlwmanifest.xml, xmlrpc.php
env_secrets	.env, .env.production, /app/.env, /backend/.env, etc.
git_repo	/.git/config, /.git/HEAD
alfa_webshell	alfacgiapi, ALFA_DATA — ALFA Team webshell fingerprints (scanner looking for already-compromised sites to piggyback on)
sql_dump	.sql, .sql.gz, backup.zip, dump.tar.gz, wp-config.php.bak
admin_panel	phpmyadmin, adminer, phpinfo, /administrator, /.aws/credentials
tenant_targeted	any path containing your brand name as a substring (e.g. /acme-widgets-db.sql)

Probe paths are priority-boosted in the rollup so they always survive the top-24 cut against legitimate 4xx traffic (missing images, expired deep links).

Three independent trip conditions, evaluated per (ASN, country) on the slow (hourly) cron:

1. distinct_probe_paths ≥ 20 in 60 minutes → warning. Classic scanner fingerprint.
2. distinct_probe_families ≥ 3 in 60 minutes → critical regardless of request count. Cross-category scanning demonstrates more capable tooling.
3. Any tenant_targeted probe at count ≥ 1 → critical immediately. A scanner using your brand name in the URL has pulled your identity from somewhere and is running a targeted kit — far more specific than a generic pass.

Default thresholds:

Parameter	Value
window_minutes	60
min_distinct_paths	20
min_distinct_families	3
enable_tenant_targeted	true

Dimension key: asn:<ASN>|cc:<country> — same shape as asn_spike, so incident correlation groups probe + spike alerts on the same ASN into one incident.

What makes this detector powerful: it's the first in the stack that can see reconnaissance before it turns into an actual attack. If someone's going to try something bad, they usually look first. This detector surfaces the looking.

Preferred mitigation: Cloudflare WAF rate-limit on the ASN, not a block. Scanner ASNs are often shared with legitimate traffic (AWS, DigitalOcean, Hetzner) and blocking the whole range will hit real users. A rate-limit at ~10 req/min is lethal to a scanner without affecting humans.

For deeper treatment see the dedicated Probe & Scanner Detection article — covers family-by-family mitigation advice and the tenant-targeted response playbook.

Daily detector

Certificate Expiry

Monitors SSL/TLS certificates for domains in your inventory. Runs daily after the certificate probe completes.

When it trips: a certificate's days until expiry falls below the configured thresholds (default: 30d info, 14d info, 7d warning, 1d critical).