Skip to main content
Flarehawk continuously analyzes your Cloudflare HTTP and WAF logs against 38 detection rules, generating an alert whenever a measured signal crosses its adaptive threshold. Rules fall into two categories: statistical rules that apply mathematical tests against live traffic metrics, and ML-based rules that run deep learning models to catch complex patterns no single metric can capture. Together, these two layers give you broad coverage across security threats, performance degradation, and behavioral anomalies—without requiring manual threshold tuning.

​
Two detection categories

Statistical rules compute a metric (request rate, error ratio, auth failure count, and so on) over a rolling window, then compare it against a per-domain adaptive baseline. When the signal exceeds the learned threshold, the rule fires. These rules cover 25 of the 38 total rules and run on all domain tiers. ML-based rules feed traffic features into an ensemble of models that assign an anomaly score. When that score exceeds its adaptive threshold, the rule fires and the alert includes a confidence value. ML rules are available exclusively on Complete tier domains.
Basic tier domains run the 25 statistical rules. Complete tier domains run all 38 rules, including the 5 ML-based rules and the 8 ML/deep learning rules in the full catalog.

​
What makes a rule fire

Each statistical rule evaluates a signal—a numeric measurement aggregated over a time window (typically one to five minutes). That signal is compared against an adaptive baseline built from your domain’s historical traffic. A rule fires when:
  1. The signal exceeds the baseline mean by more than the configured threshold.
  2. The signal is also meaningfully above baseline in absolute terms (a minimum advance prevents noise from triggering rules on low-traffic domains).
  3. The condition has persisted for the required number of consecutive minutes (usually two to three).
For ML rules, the equivalent trigger is an anomaly score that exceeds a percentile threshold learned from your domain’s traffic history.

​
Severity levels

Every alert carries one of three severity levels: Severity is not a fixed property of a rule—it is determined by how far the signal has deviated from its baseline at the moment the rule fires. The same rule can produce a warning during a minor spike and a critical during a severe attack.

​
Cooldown periods

Once a rule fires, it enters a cooldown period during which it will not fire again for the same domain. Cooldowns prevent your alert feed from flooding with duplicate notifications while an ongoing event is still active. Cooldown durations vary by rule:
  • Short-duration rules (error ratio, WAF burst): 5–10 minutes
  • Rate and volume rules: 20–30 minutes
  • ML rules: 10–60 minutes
When the cooldown expires, the rule checks whether the signal has subsided. If the condition is still present, a new alert fires immediately. If the signal has returned to normal, the rule resumes standard monitoring.
Cooldowns are per-domain. An active cooldown on one domain does not affect detection on any other domain in your account.

​
Log datasets

Each rule targets one or more log datasets: Most security and behavioral rules target HTTP logs. WAF-specific rules (such as waf_rule_burst and abuseipdb_blacklist) target WAF events or both datasets. Rules only use fields that exist in their declared dataset, which prevents mismatches between log types.

​
Per-domain rule configuration

You can enable or disable individual rules for each domain in your account without affecting other domains.
1

Open Detection Settings

In the Flarehawk dashboard, navigate to Settings → Detection for the domain you want to configure.
2

Find the rule

Browse or search the rule catalog. Each rule shows its current enabled state and the default severity mapping.
3

Toggle the rule

Use the toggle next to the rule name to enable or disable it. The change takes effect within one minute.
Disabling a rule prevents it from generating alerts, but Flarehawk continues building the baseline for that rule in the background. If you re-enable the rule later, detection begins immediately with a fully calibrated baseline.

​
Detection latency

Flarehawk targets a detection latency of under two minutes from the time a log event is ingested to the time an alert appears in your dashboard. The typical path is:
  1. Cloudflare Logpush delivers a batch of HTTP or WAF events to your Flarehawk ingest endpoint.
  2. Flarehawk stores the events and immediately queues an analysis task.
  3. The detection engine evaluates all enabled rules against the batch and writes any triggered alerts.
  4. The dashboard reflects new alerts on the next polling cycle (every 30 seconds).
Under normal conditions the end-to-end time is well under 90 seconds. Latency can increase briefly when ingest volume spikes.