Because your application logs have three blind spots, and a jail that reads only them is blind to all three.
First, anything your CDN already blocked at the edge never touches your server, so it is never logged. Second, some backends never write logs at all. Third, a flood of perfectly successful 200s leaves no 4xx trail to spot - your alarms watch for errors, and there aren't any.
The scanner that causes this is the one that avoids your honeypot paths: it still floods you, enumerating hundreds of URLs. Edge rate limits slow each burst, but the same IP keeps coming back, and every request still costs you an edge invocation or a server hit. You want repeat offenders promoted from "throttled every time" to "dropped before they reach anything".
The fix is a small scheduled job that finds IPs crossing a velocity threshold in a short rolling window and promotes them to an edge IP block. But the choice that actually matters is where you read the signal from: prefer your CDN's analytics API over your own logs. The CDN sees every single request, its real status code, and the real client IP - including the traffic it blocked at the edge and the traffic to backends that never log a line. Reading from there closes all three blind spots in one move.
Two practicalities: auto-expire each block so stale rules do not pile up, and lengthen the block for repeat offenders. And keep an allowlist, so a verified crawler or your own infrastructure never gets jailed by a velocity rule.
Full item with the query shape: https://www.tigzig.com/security/perimeter.
← All Agents FAQ