The Bot Events page provides real-time visibility into detected bot-related activities across an environment. This page is crucial for monitoring bot interactions, analyzing their impact, and taking appropriate action against malicious or suspicious activities.
Bot events represent individual occurrences of bot-related activities, typically flagged based on specific threat types such as Browser and Device Risk or Bot Risk. Security teams use this page to identify patterns, track trends, and respond effectively to automated threats.
Exploring the Events Table
Below the traffic graph, the Events Table provides a detailed breakdown of individual bot events. The table includes:
Endpoint – The affected API endpoint where bot activity was detected.
IP Address – The source IP address associated with the bot activity.
Threat Type—the classification of the bot-related activity, such as Bot Risk — Spike in API Call Count or Client Fingerprint Validation Anomalies.
Detection Time – The timestamp when the bot activity was identified.
Action – The response applied to the detected event, such as Allow, Block, Captcha, or Monitor.
Security analysts can filter the table based on specific criteria to isolate particular threats, track recurring patterns, or investigate suspicious traffic sources.
.png)
Diving into Event Details
Clicking on an event opens the Event Details panel, offering a granular view of the detected bot activity. This section includes:
Span ID – A unique identifier for tracking the specific event.
Endpoint & IP Address – The API endpoint and source IP associated with the event.
Threat Type – The classification of the bot activity.
Timestamp – When the event occurred.
Rules and Policy Enforcement
The Rules section displays:
Policy Group – The security policy under which the bot event was flagged.
Rule Name – The specific detection rule that identified the event.
Action – Whether any predefined action, such as blocking or monitoring, was taken in response.
This section is particularly useful for understanding why an event was flagged and whether detection rules need adjustment.
Request and Response Viewers
This panel provides a full view of the raw request and response that triggered bot detection, allowing you to validate the event, investigate intent, and assess impact.
Request Viewer
The Request Viewer shows the exact HTTP request sent by the client, including:
Headers — These can reveal anomalies in User-Agent, origin headers, authorization tokens, or fingerprinting headers (for example,
traceableai_jwt_testeheader,x-forwarded-for). Sudden changes in these can signal spoofing attempts or bot automation.Body — The payload can indicate intent. For example, a registration request with junk email, reused values, or rapid repetition can indicate scripted abuse.
Cookies — Examine cookies to validate whether the session appears human-like (e.g., presence of behavioral tracking cookies) or machine-generated.
💡 How to use it:
Look for patterns that violate expected behavior—missing headers, malformed tokens, identical payloads across requests. Repeated patterns across multiple bot events strengthen the detection signal.
Response Viewer
The Response Viewer shows how your application handled the request.
Was the request allowed, redirected, served an error, or challenged with CAPTCHA?
An empty response body may indicate a challenge or early rejection.
Matching this response with the request context helps you understand if your protection strategy was applied correctly.
💡 How to use it:
Check whether the application returned a 200 OK, an error (for example, 401, 403), or served a challenge. If your policy is to block the request, but you see a 200 OK, there may be a gap in enforcement.
Using This Section to Investigate Effectively
When triaging a bot event:
Start with the headers – Look for automation clues like non-browser User-Agents, repeated IPs, missing cookies.
Check the request body – Does it look human-generated? Are values repeated across different bot events?
Review the response – Did your backend behave as expected (block, allow, redirect)?
Correlate attributes below – Use metadata like
enduser.id,deployment.environment,http.status_codeetc. to trace patterns across sessions or attackers.
Taking Action on Bot Events
Once an event has been analyzed, security teams can decide how to respond. Actions include:
Monitor – Continue tracking the bot activity without immediate enforcement.
Block – Actively prevent further bot interactions from the identified source.
Captcha – Indicates a CAPTCHA challenge was shown to the user who accessed the API, typically as a verification step to distinguish bots from legitimate users.
By continuously analyzing and refining detection rules, security teams can maintain a proactive defense against evolving bot threats while minimizing false positives.