ASN Spike Detector

What it detects

The ASN spike detector catches a single autonomous system (network) suddenly sending many times more traffic than its own recent average — the classic "single source decided to scrape us" pattern.

The detector is tuned differently for different kinds of network. Datacentre egress (AWS, Google Cloud, Azure) fires at a low 3× multiplier because any meaningful retail volume from those networks is almost always bot traffic. Residential ISPs (BT, Comcast, Telstra) fire at a much higher 15× multiplier because normal morning ramp-up from sleepy overnight traffic routinely produces a 5× swing — tripping on that would flood the alert page every morning.

How it works

Two Analytics Engine queries run every minute, both grouped by (ASN, country):

1. Current window (default 5 minutes): total requests per (ASN, country)
2. Baseline window (default 60 minutes): total requests per same tuple

The detector computes requests-per-minute for both windows. For each (ASN, country) pair, it looks up the ASN's network type and applies the matching threshold. When the current rate exceeds the baseline rate by the type-specific multiplier AND the absolute volume exceeds the type-specific floor, it trips.

Why country-scoped? Traffic shape varies enormously by timezone. At 9am London time it's 4am New York, 3pm Tokyo, midnight Sydney. A single baseline across regions is meaningless: there is always a region where "right now" is peak and another where "right now" is dead. Scoping the baseline by country means BT in the UK is compared against UK history — not against a sleeping-overnight baseline polluted by other regions.

Default thresholds by network type

Network type	Multiplier	Min requests	Rationale
Datacentre / cloud (AWS, Google, Azure, OVH, DO, Linode…)	3×	1,000	Retail traffic from datacentre egress is almost always bot-driven
VPN / proxy (M247, Datacamp, Clouvider, Stark Industries…)	2×	500	VPN egress to retail is 90%+ abuse — fire aggressively
Transit / backbone (Hurricane Electric, NTT, Cogent, Lumen…)	10×	20,000	Tier-1 traffic in HTTP logs is rare; when it appears something unusual is going on
Residential / mobile ISP (BT, Sky, Comcast, Verizon, Telstra…)	15×	50,000	Diurnal + weekly swings are the norm; tolerate much more before firing
Unknown (not yet classified)	5×	10,000	Original defaults — safe middle ground

Unknown ASNs behave exactly as the original (pre-v2) detector did. The ASN classification lookup lives in blankitt-edge/src/lib/asn-type.ts; new ASNs can be added there and rolled out without a schema change.

Severity

• Warning: rate exceeds the type-specific multiplier
• Critical: rate exceeds 3× the type-specific multiplier (e.g. 9× for cloud, 45× for ISP), OR the (ASN, country) has no prior history at all (new traffic source above the volume floor)

Dimension key format

Alerts are keyed as asn:<asn>|cc:<country>. A single ASN hitting you from multiple regions will surface as multiple alerts — useful for telling a UK-only probe from a global one. The Alerts page natural-language summary renders this as "🇬🇧 Cloudflare (AS13335) · GB is sending 2.7× its normal traffic…".

When to tune

• Lower a type's multiplier (e.g. cloud → 2×) for earlier warnings on datacentre traffic
• Raise a type's multiplier if legitimate flash sales from a specific ASN class cause false positives
• Raise min_requests for a type if low-traffic networks create noise
• Override via the Rules page. The per_type JSON block is editable per tenant; flat fields remain the fallback for unknown networks.

Reading the context on an alert

Open an alert's Rule details panel to see:

• asn_type — what class the detector put this ASN in
• country — which country was scoped
• multiplier_applied and min_requests_applied — which threshold values fired

If an ASN is classified wrong (e.g. a new cloud provider we haven't catalogued ending up as other), flag it so we can add it to the classifier.