Every DDoS tool blocks your own users
Static thresholds, short learning windows, and aggressive auto-blocking cause DDoS tools to treat legitimate traffic as attacks. The result is self-inflicted downtime that is worse than the threats they claim to prevent.
Root causes
Why DDoS false positives happen
False positives are not a tuning problem you can fix with better thresholds. They are a structural problem with how most detection systems define "normal."
Static thresholds
Most tools ask you to set a fixed threshold: "alert if traffic exceeds X Gbps." But normal traffic is never constant. A game server at 2pm looks nothing like the same server at 10pm. A flash sale on Black Friday looks like an attack to any static threshold set for normal Tuesday traffic. Operators end up padding thresholds so high that real attacks slip through, or leaving them tight enough that normal spikes trigger blocks.
Short learning windows
Some tools offer "learning mode" that watches traffic for a few hours and sets a baseline. The problem is obvious: if the learning window does not capture your peak hours, weekend patterns, monthly billing cycles, or seasonal events, the baseline is wrong from day one. A few hours of observation cannot represent weeks of real traffic variation.
Aggressive auto-blocking
When detection is coupled with automatic blocking, false positives become outages. A tool that auto-blocks traffic above a threshold will drop legitimate connections without anyone making a decision. Enterprise vendors often recommend starting in "detection only" mode for weeks before enabling blocking, which means you are unprotected during the learning period.
Threshold flapping
When traffic oscillates near a threshold, detection toggles rapidly between "attack" and "clear" states. Each toggle can trigger alerts, mitigation actions, and withdraw sequences. A busy server hovering near its threshold can generate dozens of false alerts per day, training operators to ignore all alerts entirely.
The consequence
The false positive spiral
False positives create a predictable spiral. First, the tool alerts too often. Operators start ignoring alerts because most of them are false. Then a real attack hits and nobody responds because the team has been conditioned to treat every alert as noise. Management disables automated responses to prevent more self-inflicted outages. Now the tool is in detection-only mode with thresholds so padded that only catastrophic attacks trigger anything. At that point, you are paying for a very expensive log viewer.
The worst version of this is when a false positive triggers upstream mitigation. An RTBH announcement triggered by a false positive will blackhole all traffic to the target IP, creating a total outage for that server. If automated FlowSpec rules fire on a false positive, they can block entire traffic classes that include legitimate customer connections.
The technical fix
How adaptive baselining works
The alternative to static thresholds is a system that continuously learns what normal looks like for each individual server and adjusts its thresholds automatically.
Static threshold vs. adaptive baseline
A static threshold set at 1 Gbps will miss a 600 Mbps attack during morning hours (when normal traffic is 300 Mbps) but false-positive on a legitimate 900 Mbps flash sale event in the evening. The threshold is simultaneously too high and too low.
An adaptive baseline tracks what each server's traffic actually looks like over a rolling window and sets the detection threshold relative to that pattern. A 600 Mbps spike during a 300 Mbps baseline period is suspicious. A 900 Mbps spike during a period where traffic has been steadily climbing to 750 Mbps is probably not.
How Flowtriq addresses this
Three mechanisms that reduce false positives
Sliding-window p99 baselines
Flowtriq maintains a rolling window of 300 traffic samples per server and calculates the p99 value as the baseline. The threshold adjusts continuously as traffic patterns change. Each server gets its own baseline, so a busy web server and a quiet DNS server are not held to the same standard.
90-second startup grace period
When the agent first starts or restarts, it spends 90 seconds collecting baseline data before activating detection. This prevents the agent from alerting on whatever traffic happens to be flowing during the first few seconds of operation, which is a common source of false positives with tools that try to detect immediately.
10-tick hysteresis
Once an attack is detected, Flowtriq requires 10 consecutive below-threshold samples before declaring the attack resolved. This prevents the "flapping" problem where traffic oscillating near the threshold generates dozens of alert/clear cycles. The attack stays active until traffic is clearly and consistently below threshold.
Where we're still improving
Building a feedback loop so the system learns from user-marked false positives and adjusts future detection sensitivity. Adding time-of-day baseline awareness for servers with predictable traffic patterns, like gaming servers with evening peaks or e-commerce sites with weekend surges.
Frequently asked questions