Does a traffic spike prove an attack?¶
No. Public interest, campaigns, releases, backups, updates, replication and misconfiguration can all produce abnormal traffic. A spike is a reason to investigate, not a conclusion.
Inspect the underlying events¶
Compare source distribution, requests, target service, user agent, success and error rates, resource effect and historical baseline. Use the same service, time, season and business context rather than an unrelated organisation-wide average.
Repeated requests, spoofing or automation may support attack but none is decisive alone. Known sources can be compromised; unfamiliar sources can be legitimate.
Check measurement and sequence¶
A surge after service failure may be legitimate user retries rather than the original cause. Monitoring changes or duplicated telemetry can also create an apparent spike.
Preserve how metrics were produced and do not compare bytes, packets, requests and connections as if interchangeable. Obtain raw traffic and application events behind summary graphs or alerts.
Key takeaway
Treat a traffic spike as an investigative trigger, testing request pattern, system impact, business context and measurement before classifying it as attack.
