To distinguish bot traffic from a legitimate traffic spike, compare the requests with the work users are completing and the resources the service is consuming. Volume, geography, and user-agent strings are clues. None settles the cause by itself.
Keep three hypotheses open at the start: real demand increased, automated activity increased, or a service change made ordinary traffic more expensive. More than one can be true.
Begin with the affected journey
Identify what changed for users: slow search, failed login, delayed downloads, or general unavailability. Compare the time of that change with traffic, deployments, campaigns, and dependency incidents.
Google's SRE monitoring guidance uses latency, traffic, errors, and saturation to describe service health. It also separates symptoms from causes. Apply that discipline before assigning an attack label to a busy graph.
Use the same time window and observation point when comparing metrics. Edge requests, origin requests, application sessions, and analytics events count different things.
Test competing explanations
| Hypothesis | Evidence to seek | Evidence that weakens it |
|---|---|---|
| Legitimate demand | Expected entry pages and completed workflows | Little useful activity after repeated expensive requests |
| Approved automation | A known owner and documented workload | Unexplained operations outside its scope |
| Abusive automation | Repeated policy violations or extraction behavior | A confirmed permitted integration matching the pattern |
| Application regression | Cost or failures rise after a change | Stable execution cost while external demand changes |
| Retry amplification | Repeated operations after errors or timeouts | Independent successful operations explain the volume |
Treat “evidence that weakens it” as an invitation to investigate, not as a definitive exclusion rule.
Avoid inferring intent from a new country or a shared network. A public link can bring an unfamiliar audience. A mobile provider may place many legitimate visitors behind the same address.
Work through a hypothetical launch
Suppose a feature announcement brings visitors to a page that immediately requests search suggestions. Search latency rises, browsers retry, and the origin receives more calls than the public page-view count suggests.
That sequence could resemble a bot flood if the investigation begins and ends with repetitive API requests. Before blocking, inspect the frontend request behavior, error timing, and relationship between visits and search operations.
Now suppose a separate client repeatedly traverses search results without performing the announced workflow. That may be an independent automation problem. Split the populations rather than forcing the whole incident into one explanation.
The example is a diagnostic exercise, not a reported Centinel incident.
Compare completed work, not only engagement proxies
For an application, use a relevant server-side outcome: a successful search result, an authorized record read, or a completed workflow. Analytics engagement can add context, but missing analytics does not prove automation.
Conversely, a bot can complete a workflow. A completed operation establishes what happened, not whether it was permitted. Compare the result with the client's allowed purpose and usage.
For analytics-specific questions, use bot traffic in Google Analytics. Keep event filtering separate from a decision about serving requests.
Contain the harm while uncertainty remains
You may need to protect an overloaded operation before attribution is complete. OWASP's denial-of-service guidance emphasizes the resource and architectural layer under strain.
Choose a bounded, reversible control on the affected work. Monitor the legitimate journey while it is enforced. Record whether the change reduced the actual bottleneck and who was affected.
If the evidence supports an application-layer attack, continue with the layer 7 response guide. The traffic flood use case is the product context. Keep the diagnosis record: it prevents a temporary hypothesis from becoming a permanent blocking rule.