Traffic analysis and anomalies
Read attack baselines, timestamps, request outcomes, source attribution, and coverage gaps.
Traffic analysis compares current edge observations with service baselines to identify volumetric and application-layer anomalies. An anomaly can be an attack, a legitimate demand spike, a release change, or a collection problem.
Open Network protection → Services → Service → Traffic. Choose a time range and inspect received traffic, allowed traffic, dropped traffic, origin requests, response classes, and latency. Units are explicit: bytes per second, packets per second, or HTTP requests per second. These series measure different stages and must not be added together as unique requests.
Investigate an anomaly
At Network protection → Anomalies → Anomaly, compare the baseline window, affected protocol and path, client distribution, triggered rules, and backend health. A new service has limited history; the view marks a learning baseline rather than presenting it as a mature prediction. Scheduled releases and marketing events can change normal traffic.
Top-source views use the edge's validated client identity. Proxies and shared NAT can aggregate unrelated clients. Geography and network ownership are context, not a confirmed actor identity. Link related intelligence matches to an incident before attributing an attack.
Observation boundaries
Dashboard occurrence time and ingestion time can differ. Filtered views and delayed delivery can produce apparent gaps. Open Service → Coverage to distinguish no traffic from no reporting. Edge observations do not measure traffic bypassing the edge or traffic lost upstream before it arrives.
Use Traffic → Export report for a bounded view with filters, collection cutoff, and known gaps. Payload evidence has separate permissions and retention from aggregated traffic. A high drop count does not demonstrate recovery; verify the application owner's successful transactions and origin health. Use reports and retention for preserved records.