The Bot Activities page provides a deeper look into bot-related incidents detected across your environment. Unlike the Bot Protection Dashboard, which gives a high-level summary, this section is designed for detailed analysis. It helps security teams understand the nature of bot attacks, track trends over time, and take appropriate action to mitigate threats.
Bot activity is rarely random—most attacks follow recognizable patterns that evolve over time. This page provides the tools necessary to stay ahead of these threats. By leveraging traffic insights, incident tracking, and backtesting capabilities, security teams can fine-tune their defenses, minimize false positives, and rapidly respond to automated threats.
More than just a detection tool, the Bot Activities page supports proactive defense strategies. With a structured workflow—from initial detection to in-depth analysis and response—organizations can maintain a strong security posture against ever-evolving bot threats.
Analyzing Traffic and Incident Trends
At the top of the page, the Total Traffic Timeline graph presents a dynamic view of bot activity. Traffic is represented by a blue line, while detected bot-related incidents appear in red. This dual-layered visualization allows users to compare bot activity against standard traffic patterns, helping to identify unusual spikes that could indicate an attack in progress.
Security analysts can toggle between Traffic and Active Incidents or view both simultaneously to better understand emerging threats. A sudden increase in bot-related incidents without a proportional rise in overall traffic might suggest that detection rules have been tightened. In contrast, a simultaneous increase in both metrics could indicate a large-scale automated attack.
Understanding Bot Incidents and Their Impact
Below the timeline, the Incident List provides a detailed breakdown of detected bot activities. Each row represents an incident—such as a sudden spike in API call counts—and highlights critical details, including the target endpoint, the duration of the incident, and when it was last observed.
Filtering options allow users to narrow down incidents based on incident type, affected targets, and last seen. This is particularly useful when investigating a persistent bot attack targeting specific services or APIs. If multiple bot-related incidents share common attributes—such as originating from the same endpoint—this could indicate a coordinated attack that requires immediate attention.
Diving Deeper into Incident Details
Clicking on an incident reveals an in-depth analysis of its characteristics. This section provides the necessary details to determine the impact of the bot activity and plan an appropriate response.
Summary Tab
The Summary tab provides an overview of the incident, including:
First Detected / Last Detected – The timeframe in which the bot activity was observed.
Blocked Events / Monitored Events – The count of bot requests that were either blocked or monitored.
Detection Fingerprints – Specific attributes, such as request headers, cookies or payload signatures, that were used to classify the traffic as bot-generated.
Understanding Fingerprints in the Summary Tab
Fingerprints are key in identifying bot activity and are derived from detection policies. These fingerprints represent specific attributes—such as request headers, user-agent patterns, request body types, or missing authentication tokens—that indicate bot behavior.
Each fingerprint listed represents a detection signal derived from Traceable's bot detection rules. The table includes the following fields:
ID – A unique identifier for the fingerprint. Hovering over the info icon reveals the full detection condition (e.g., specific header, user-agent pattern, etc.).
Status – Indicates whether the fingerprint's enforcement is currently active. If marked Expired, the fingerprint is no longer actively used for enforcement. If Active, any requests that match the fingerprint will be handled based on the associated action.
Action – Users can choose how to handle traffic matching each fingerprint:
Allow – Let traffic through without blocking.
Monitor – Observe and log the traffic without blocking.
No Action – Keep the fingerprint defined but take no enforcement action.
By fine-tuning fingerprint actions, security teams can reduce false positives, improve detection accuracy, and ensure legitimate traffic is not mistakenly blocked.
.png)
Total Traffic Timeline
The Total Traffic Timeline graph within the Summary tab provides a time-based visualization of bot-related traffic patterns. It includes:
Total Traffic (Blue Line) – The total number of requests observed within a given time window.
Blocked Traffic (Red Line) – The number of requests that were explicitly blocked by bot protection rules.
Detection Time (Orange dots) – Highlights when the bot activity was detected.
Hovering over any data point in the graph reveals a breakdown of request volume at that timestamp, providing insights into traffic surges and detection accuracy. This timeline helps security teams correlate bot activity trends, understand when attacks peaked, and assess whether mitigation efforts were effective.
Backtesting Tab
The Backtesting feature allows security teams to validate detection rules by analyzing historical traffic. This tab provides insights into:
How often would the fingerprint have matched in historical data?
Whether the rule needs fine-tuning to reduce false positives or false negatives.
A visualization of bot request trends across different time intervals.
Using the Fingerprint Source
The Source dropdown in the Backtesting tab allows you to select specific fingerprints to analyze. Each fingerprint represents a detection pattern applied to bot traffic. Selecting a fingerprint applies its detection criteria to historical traffic, providing a clear view of how that fingerprint performed over time.
You can:
Compare multiple fingerprints to identify patterns in bot activity.
Validate rule effectiveness before enforcing stricter actions.
Detect recurring bot behavior across different periods.
Time Period
Next to the Source dropdown, the Time Period dropdown allows you to specify a historical range (e.g., last 30 minutes, 1 hour, or longer) to analyze how a fingerprint performed over that timeframe. This is particularly useful when trying to correlate bot activity spikes with known attack windows, helping security teams fine-tune detection rules more effectively.
By running a backtest, you can see how these fingerprints would have matched past traffic patterns, ensuring detection rules are neither too strict nor too lenient. If too many false positives appear, refining the fingerprint ensures legitimate users are not mistakenly blocked. Conversely, adjusting the detection parameters can improve accuracy if bot traffic is slipping through.
Backtesting enables a data-driven approach to bot mitigation, allowing teams to refine detection strategies before applying policies in live environments.
Taking Action on Bot Activity
Once an incident has been analyzed, security teams can take action using the available response options:
Allow the traffic if it was mistakenly flagged as bot activity.
Monitor the traffic to observe further behavior before making a final decision.
Block the traffic if it is confirmed as malicious bot activity.
These options ensure flexibility in bot mitigation, allowing teams to tailor their response strategies based on real-time insights. For example, if an endpoint is frequently targeted by credential stuffing attacks, an administrator might choose to monitor traffic initially, gathering more data before moving to a full block.
Best Practices for Effective Bot Mitigation
Choosing the right response action is critical to maintaining a balance between security and user experience. Here are some best practices to guide decision-making:
When to Monitor: If an incident involves high traffic but low risk, monitoring can help assess behavioral patterns before applying strict blocking measures. For example, an API endpoint experiencing increased traffic from a single IP may not immediately warrant blocking if legitimate users are involved.
When to Block: Blocking should be applied when repeated malicious behavior is detected, such as a bot attempting credential stuffing attacks or scraping sensitive data at high frequency.
When to Adjust Detection Rules: If false positives are high, fine-tune bot detection by reviewing fingerprints in the Backtesting tab. Adjusting rules ensures that legitimate users are not mistakenly blocked while keeping bot threats contained.
By continuously refining detection policies and balancing enforcement actions, security teams can minimize false positives, reduce risk exposure, and optimize bot defense strategies.
Investigating Bot Behavior Through Traffic Analysis
Beyond high-level incident tracking, the Bot Activities page enables deep forensic analysis. Security analysts can inspect traffic details such as:
The affected service and endpoint where bot activity was detected.
The status codes and request details to determine whether attacks were successful.
The headers and payload data associated with bot requests.
By reviewing this granular data, teams can pinpoint how bots interact with applications and identify patterns that might require custom detection rules. The platform even allows the creation of custom blocking rules based on specific findings, enhancing automated defenses against sophisticated bot attacks.