> For the complete documentation index, see [llms.txt](https://docs.thousandeyes.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thousandeyes.com/product-documentation/cloud-insights/views/events-in-cloud-insights.md). # Events in Cloud Insights Events give you a record of what changed in your cloud environment and when. Cloud Insights tracks inventory events and cloud traffic events, letting you correlate infrastructure changes with traffic behavior to quickly pinpoint the cause of a disruption. {% hint style="info" %} Not all events negatively impact your applications and services. {% endhint %} ## Event Classes Cloud Insights surfaces two classes of events that reflect changes and anomalies in your cloud environment: * **Inventory events** are configuration change and operational scaling events and state changes across your virtual infrastructure. These are generated from your inventory integration and are accessible across all screens; they do not require a flow log integration to view. * **Cloud traffic events** are automatically detected anomalies in your AWS VPC, AWS Transit Gateway, and Azure VNet flow log traffic data. Cloud traffic events require an active flow log integration and are only visible on **Cloud Insights > Views**. See [Cloud Traffic Events](#cloud-traffic-events) for more information. ### Event Types In addition to inventory and cloud traffic *classes*, events are split into *types* within each class. Inventory events are divided into configuration types and operational change types while traffic events are divided into five different types: | Event Type | Category | Scope | Data Source | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | Abnormal Accepted and Rejected Throughput | Simultaneous increase in rejected traffic and decrease in accepted traffic; commonly indicates a security group change. | AWS Application Load Balancer or Network Load Balancer | AWS VPC Flow Logs | | Abnormal Throughput | Significant increase, decrease, or spike in accepted throughput. | AWS Application Load Balancer, Network Load Balancer, NAT gateway, or Transit Gateway attachment; Azure Application Gateway; between regions in AWS or Azure; AWS account or Azure subscription | AWS VPC Flow Logs, AWS Transit Gateway Flow Logs, Azure VNet Flow Logs | | Abnormal Rejected Throughput | Significant change in rejected throughput. | AWS Application Load Balancer or Network Load Balancer | AWS VPC Flow Logs | | Abnormal Connections | Significant change in connection rate; includes detection of TCP SYN flood patterns. | AWS Application Load Balancer, Network Load Balancer, or NAT gateway; Azure Application Gateway; between regions in AWS or Azure | AWS VPC Flow Logs, Azure VNet Flow Logs | | Abnormal Rejected Connections | Significant change in rejected connection rate; includes ML-based anomaly detection and TCP SYN flood pattern detection. | AWS Application Load Balancer or Network Load Balancer | AWS VPC Flow Logs | ## Viewing Events You see different classes of events depending on the screen you’re viewing. | Screen | Inventory Events | Cloud Traffic Events | | ---------------------------------------------------------------------- | ---------------- | -------------------- | | **Cloud Insights > Views** (**Events** tab) | Yes | Yes | | **Cloud Insights > Inventory** (**Events** metric) | Yes | No | | **Network & App Synthetics > Views** (**Cloud** layer, **Events** tab) | Yes | No | Events are represented in each screen as a swimlane below the timeline and in the accompanying table when you select the **Events** tab or metric. You can also filter by event type in the global filters. * In **Cloud Insights > Inventory**, select **Events** from the **Metrics** selector at the top left of the page. Use the chart [time range](https://docs.thousandeyes.com/product-documentation/cloud-insights/views#selecting-a-time-range) and [data window](https://docs.thousandeyes.com/product-documentation/cloud-insights/views#time-span-selector) to change how many events you view; all inventory events in the specified time window load in the table beneath. Operational events are highlighted in blue and configuration change events are highlighted in green. Only events stemming from the inventory integration are viewable on the Inventory screen; you will not see cloud traffic events, which require a flow log integration. ![Cloud Insights Inventory events](/files/HrAhsdX1eNLZMz931z6k) * In **Cloud Insights > Views**, select the **Events** tab beneath the chart to view all events within the selected time window. Both inventory events and cloud traffic events appear here, highlighted in the swimlane in pink and purple, respectively. ![Cloud Insights Views events](/files/87aXikr0Mr3i7wQ5ife6) * In **Network & App Synthetics > Views**, select a time slice in the **Cloud** layer timeline to see inventory events listed in the **Events** tab underneath. Cloud traffic events are not shown in this view, and you can currently only view events per 5-minute interval, not all events within the chart time span. ![Network & App Synthetics Views events](/files/zdN58DTMEvIXTyRjulry) To control how much historical event data is displayed, see [Selecting a Time Range](https://docs.thousandeyes.com/product-documentation/cloud-insights/views#selecting-a-time-range) and [Time Span Selector](https://docs.thousandeyes.com/product-documentation/cloud-insights/views#time-span-selector). To control which inventory event types are displayed, see [Events Configuration](https://docs.thousandeyes.com/product-documentation/cloud-insights/settings#events-configuration). ## Viewing Event Details In all screens, the event table offers the following details about the event: * **Event Type**: The name of the detected anomaly type (for example, Abnormal Throughput). * **Category**: A more specific description of the anomaly and its scope (for example, "Anomaly detected in throughput of an application load balancer"). * **Resource Name**: The name of the affected cloud resource. * **Resource Type**: The type of resource (for example, Application Load Balancer). * **Date (Timezone)**: The date and time when the event occurred. * **Account**: The cloud account in which the resource resides. * **Region**: The geographic area in which the cloud resource is hosted. * **Availability Zone**: Where applicable, the location within a region the affected resource was deployed in at the time of the event. You can select any single event from the table to open a side panel with further event details. Cloud traffic events show the following by default. For inventory events, select the **Additional Details** tab to view: * **Details**: A plain-language description of the event. * **Confidence score** (for cloud traffic events only): An indicator of how reliably the system considers this to be a real anomaly. See [Understanding Confidence Scores](#understanding-confidence-scores). * **Resource Creation Time**: The timestamp at which the cloud resource was originally provisioned, as distinct from the event timestamp, which reflects when the change or anomaly occurred. * **Resource ID**: The resource identifier; for AWS resources, this is the Amazon Resource Name (ARN). * **VPC** or **VNet**: The virtual network to which the affected resource belongs. Cloud Insights displays **VPC** for AWS resources and **VNet** for Azure resources. * **Subnet**: The IP address range within the VPC or VNet associated with the affected resource. ### Viewing Inventory Event Diffs When you click an inventory event to open the details side panel, you view the diff of the configuration or operational change by default. Scroll down the diff to view all the changes in the event. ![Inventory change diff](/files/gGy58fGa96e08Hcwji4c) ## AI-Assisted Event Analysis In all screens, the Cisco AI Assistant is available when events are visible in the **Events** table. {% hint style="warning" %} The Cisco AI Assistant is not available in the ThousandEyes for Government instance. {% endhint %} There are two ways to invoke the assistant: * **Summarize Events**: When one or more events are visible in the **Events** table, a **Summarize Events** button appears above the table. Click it to send all visible events to the AI assistant for a consolidated analysis. The assistant returns a structured summary that includes: * A brief overview of the events. * Key events with their timestamps. * Possible causes or configuration changes (inventory events only). * Potential impacts. * Recommendations. Each category is presented as a collapsible section. After the initial summary, you can ask the assistant follow-up questions in the AI panel. ![Summarize Events button](/files/rLtO0TRyVof2e6phWGA5)

The AI assistant can analyze up to 100 events simultaneously, while total prompt characters are limited to 1000. If you go over either limit, you will not be able to access the Summarize Events button. A counter shows you how many events or characters over the limit you are.

To decrease event numbers, narrow your time window or apply filters to unlock the button. The prompt character limit is caused by too many filter items being selected. To decrease prompt characters, try narrowing the timeline further to the events you want to inspect, then reduce the number of filters.

* **Summarize Event** (inventory events only): When you select a specific inventory event row to open its details, a **Summarize Event** button appears in the sidebar. Click it to request an AI-generated explanation of that individual event, including what changed and what the consequences might be. ![Summarize Event button](/files/3ksKOO7yxzMFa87LyGD9) Summaries are scoped to the events visible in the table onscreen. For example, in the **Cloud Insights > Views** screen with no cloud provider filter applied, the summary covers events from all providers in scope, such as AWS and Azure. On a provider-specific tab in **Cloud Insights > Inventory**, the summary is scoped to that provider's events. Cloud traffic events are included in multi-event summaries generated within **Cloud Insights > Views**. For single-event AI analysis for cloud traffic events, you must isolate the event using the filters or time window. To provide feedback on the AI response, use the thumbs-up or thumbs-down controls in the AI panel to open a free-text field where you can type in more specific details. For more information about AI-driven event summarization, AI data privacy, the error disclaimer, and opt-out options, see [Event Summarization using Large Language Models (LLMs)](https://docs.thousandeyes.com/product-documentation/event-detection#event-summarization-using-large-language-models-llms). ## Cloud Traffic Events Cloud Insights offers zero-touch anomaly detection that surfaces unusual traffic behavior across your cloud resources without requiring you to configure or maintain individual alert rules, which can be impractical when you have thousands of resources to monitor. Cloud Insights scans your flow log data, automatically records anomalies as events, and lets you investigate them in chart context immediately. Through continuous monitoring and multiple detection methods, Cloud Insights accounts for the normal traffic variation of each individual resource and only surfaces traffic behavior that deviates significantly from its established patterns. {% hint style="info" %} Cloud traffic events are available for AWS and Azure environments. AWS support covers VPC and Transit Gateway flow logs; Azure support covers VNet flow logs. {% endhint %} ### Key Benefits Cloud traffic events are designed to help you: * Surface unusual traffic changes automatically, despite complex environmental factors. * Start investigating without setting alert thresholds or custom rules first. * Prioritize investigations with a confidence score of the event's veracity. * Jump to a chart-view of the specific event so you can isolate the anomaly in context. ### How Cloud Traffic Events Work Unlike alerts, which require you to identify specific resources to monitor and configure thresholds manually, cloud traffic events require no setup. The system uses two automatic event detection methods: * **Rule-based method:** Operates in near-real time. * **Behavior-based method:** Runs hourly and accounts for historical patterns and seasonality. Rule-based events set trigger criteria per event type, which can generate near-instant events. For behavior-based events, a resource first accumulates sufficient traffic history (see [Behavior-Based Characteristics](#behavior-based-characteristics)) before the system can detect behavior outside the norm of a resource's observed pattern. Detection runs against resources that meet minimum traffic thresholds (see [Detection Thresholds](#detection-thresholds)), filtering out very low-volume resources where small absolute changes could produce noisy signals. When an anomaly is detected, an event is recorded, viewable on the timeline and **Events** table in **Cloud Insights > Views**. ### Isolating a Cloud Traffic Event You can narrow the chart to the specific event (isolating only affected resources or regions, time slice, etc.) to see the anomaly in context. Select **Filter by this event** either in the event detail panel or from the ellipsis menu (**...**) on the table. !["Filter by this event" button](/files/5tCdhnkT3zIaFuhRSvEL) The screen filters to show only traffic data for the resource scope associated with the event. The timeline shows the affected resources' traffic history, making the anomaly visible as a change in the chart. ![Filtered event](/files/DoWOraZBurtCNWmikWn0) The filter can show stacked charts when both accepted and rejected metrics inform the event, so you can see the event’s full effect. This allows you to see the traffic pattern before, during, and after the detected event in a single view. To return to the unfiltered view, click **Reset Filters**. ### Understanding Confidence Scores The confidence score in the event detail panel indicates how reliably the system considers the detected event to be a genuine anomaly rather than noise. A higher score means greater confidence in the finding. * Rule-based events always receive a confidence score of 100%. The data either matches the rule’s trigger criteria or it does not. When it matches, the system is certain by definition. * Behavior-based events receive a score from 30% to 100% on a log scale. The score is derived from how far the anomalous data point sits from the nearest normal-behavior cluster, normalized against the weakest anomaly the algorithm flagged in that batch. The log scale means moving from 90% to 100% requires a much larger distance than moving from 30% to 50%. A score in the 90s represents a strong outlier. Events that fall below the minimum confidence threshold are not surfaced. {% hint style="info" %} Confidence scores are best used as a ranking signal for investigation, not as a definitive impact score. {% endhint %} ### Detection Algorithms Cloud Insights uses two detection methods for cloud traffic events. #### Rule-Based Method The rule-based method can trigger events in near-real time (only about a 5-minute delay). As flow log data arrives, it is compared against a dynamic baseline computed using a low-pass filter; each new data point is blended into the running average with a much smaller weight than the accumulated history behind it. The baseline therefore adapts gradually to genuine long-term changes, while a brief spike shows up as a deviation rather than being absorbed as a new normal. If the incoming data meets the rule's trigger criteria, an event is generated. Example trigger criteria include rejected traffic exceeding a threshold percentage of total traffic while accepted traffic drops simultaneously. Rule-based detection is suited to scenarios with clear, fast-moving signals, such as a sudden increase in rejected connections following a security group change. #### Behavior-Based Method The behavior-based (or machine-learning (ML)) method runs once per hour. It analyzes the most recent hour of data relative to the prior 14 days of traffic history, identifying periods where the short-term pattern significantly deviates from the model's learned representation of normal behavior. Before the detection algorithm runs, flow data is prepared: raw records are aggregated into 15-minute buckets, and from each bucket a set of numerical features is derived, for example, average throughput and how much throughput varied within the interval. Each feature is then rescaled so that no single dimension can dominate the anomaly calculation. The algorithm groups data points by behavioral similarity; a point that does not fit any group is classified as an anomaly. Before grouping, predictable trends and repeating patterns, such as consistently higher weekday traffic, are removed, so the algorithm only flags behavior that genuinely departs from the resource’s adjusted baseline. Because it incorporates full historical context, including seasonality such as weekday versus weekend traffic patterns and longer-term trends, the ML method can detect more nuanced anomalies than rule-based detection. As it runs on a batch schedule rather than continuously, there is an inherent delay of up to one hour before an ML-detected event appears in the timeline. ### Behavior-Based Characteristics Behavior-based anomalies are best understood with the following characteristics in mind: * Meaningful behavior-based detection requires a historical baseline, not just a newly discovered resource. In practice, newly observed resources need two weeks of usable history before behavior-based detections become consistently meaningful and before events on the resource are triggerable. * Very low-volume or near-idle resources might be filtered out because sparse traffic is more likely to create noise than useful detections. * Event timing reflects aggregated traffic windows used for analysis, and delays in flow-log delivery from the cloud provider can also contribute to anomalies or affect the displayed event timing. You should treat the displayed event time as investigation guidance rather than an exact packet-level onset timestamp. ### Detection Thresholds Threshold filtering operates at two points in the pipeline: 1. **Before detection: resource eligibility:** A resource must exceed minimum thresholds for both throughput and flow count before it is analyzed at all. Resources below either threshold are excluded, because very low-traffic resources can show large percentage swings from minor fluctuations that would not constitute a meaningful anomaly. 2. **After detection: anomaly magnitude:** Even when a data point is classified as anomalous, if the absolute magnitude of the change is too small, the event is dropped. This prevents the system from surfacing anomalies that are statistically unusual but practically insignificant. ### A Common False Positive Cause Cloud traffic events are tuned to minimize false positives, but they *can* still occur. The most common cause is delayed flow log delivery from AWS. In some cases, AWS delivers flow log data up to one hour late. When this happens, Cloud Insights initially sees a drop in traffic, followed by a spike when the delayed data arrives. The initial drop might trigger a cloud traffic event, even though no actual anomaly occurred in your infrastructure. {% hint style="info" %} If you see a cloud traffic event but traffic looks normal when you investigate, delayed AWS flow log delivery could be the cause. {% endhint %}