Events definitions
Last updated
Last updated
Events represent key observations about your data warehouse—like inefficient pipelines, critical schema changes, or cost anomalies. They are curated signals Alvin processes from raw activity to detect inefficiencies and address operational problems.
Events power , enabling you to act on observations. They’re the foundation of Alvin’s ability to turn warehouse activity into meaningful actions—the first step towards actionable insights and eventual resolution.
You can view the raw feed of all events on the tab.
However, their true value lies in setting up Workflows that allow you to automate responses, trigger alerts, and streamline operational processes based on events. See for more information.
This is a list of all events currently available to Alvin users. We’re continually refining it based on customer feedback and our understanding of what matters most in data warehouses.
When a new anomaly was detected. Anomalies include unexpected spikes in cost or volume or quality issues such as freshness.
When an anomaly was resolved. Indicates that the anomaly’s root cause was addressed, and normal behavior resumed.
dbt model was detected as being low ROI. This means the model runs frequently but has minimal impact on data consumption.
Model was used again after previously being considered stale. Typically occurs when downstream dependencies or queries start accessing the model again.
A dbt model is considered stale after not being used for 30 days. A stale model can indicate redundancy, mismanagement, or unused data assets.
When a dbt test ran with failures. Examples include failing row checks, unexpected null values, or constraint violations.
When a dbt test ran successfully.
An entity was seen for the first time.
An entity disappeared from the system.
An entity's labels have been modified (added, removed, or value changed).
Entity was used again after previously being considered stale.
An entity's schema has been modified (fields added, removed, or types changed). Schema updates can affect downstream workloads and should be monitored for compatibility issues.
Entity is considered stale after 30 days.
When a table with a full refresh materialization is executed. Based on the processed historical data. The full refresh can be classified into 4 values based on the upstream data:
FULL_REFRESH_WITH_INCREMENTAL_UPSTREAM
FULL_REFRESH_WITH_NO_UPSTREAM
FULL_REFRESH_WITH_NO_INCREMENTAL_UPSTREAM
INCREMENTAL_WITH_UPSTREAM
When a full refresh was resolved.
Examples include unclustered large tables or tables clustered on low-impact columns. The BigQuery recommender uses the project's workload execution data from the past 30 days to analyze each BigQuery table for inefficient clustering configurations.
When an inefficient cluster config was resolved.
The Alvin recommender uses the project's workload execution data from the past 30 days to analyze each workload for inefficient BigQuery pricing configurations, for example On-demand model instead of Enterprise or the other way around.
When an inefficient pricing model was resolved.
The Alvin recommender uses the dataset table's storage data from the past 30 days to analyze each table for inefficient dataset storage configurations. Examples include using the logical storage model instead of physical or the other way around.
When an inefficient storage pricing model was resolved.
When a query insight is detected. Query insights highlight inefficiencies, redundant operations, or optimization opportunities. They are generated by the Alvin parser or integrated external tools.
When a query insight is resolved. Indicates that the suggested query optimizations or insights were applied successfully.
Unbalanced table builds lead to suboptimal pipelines and increased costs. This typically happens when tables are updated more often than their source tables.
When an unbalanced table build was resolved.
A new workload is detected when a workload is run that didn't exist before.
A workload ran with execution errors.