# Compare two workload runs to find the cause

> Compare two runs of a dbt, Tableau, or Snowflake workload and get the root cause named. The warehouse, the task count, or the code.

Source: https://altimate.ai/product-highlights/snowflake-workload-root-cause-analysis

[.md](https://altimate.ai/product-highlights/snowflake-workload-root-cause-analysis.md) 

Copy as MD

Enterprise Platform

## Root Cause Analysis for a dbt, Tableau, or Snowflake Workload Spike

Compare two runs of a dbt, Tableau, or Snowflake workload and get the root cause named. The warehouse, the task count, or the code.

Anas FarooquiJun 26, 2026Jul 31, 20266 min read

 Root cause analysis for a dbt, Tableau, or Snowflake workload spike 

TL;DR

-   **What it is.** Root cause analysis for any Snowflake workload. It covers every run of your dbt models, Tableau workloads, notebooks, stored procedures and Streamlit apps. Compare two runs and the AI names the cause: the warehouse, the task count, or the code. dbt and Tableau come in through connections you already made, and Snowflake queries need a tag so their runs group into a workload.
-   **Who it is for.** Analytics engineers, data platform leads and whoever is on call when the nightly job doubles.
-   **What you get.** You find out why the nightly job doubled, without reading three sets of logs.

## Root Cause Analysis Starts with Every Snowflake Workload Run

Your nightly job took eighty minutes last night instead of forty. Three tools each hold part of the answer, and none of them holds all of it. So you read the dbt logs, then query history, then the Tableau admin views. By the time you have an answer, the next run has already started.

The Code section reads all of it in one place. You get a run history for each of these:

-   **dbt models**, through the dbt connection you already made.
-   **Tableau workloads**, once the refresh queries carry a tag.
-   **Notebooks.**
-   **Stored procedures.**
-   **Streamlit apps.**

Under any single run you also get the child queries that ran inside it. Cost and run time sit on the same chart. A run that got expensive and a run that got slow are one investigation instead of two.

Here is one workload over 28 days. The blue line is what each run cost you. The purple line is how long each run took. Across 31 runs it averaged 22 minutes 54 seconds and $2.27, and its worst run took 1 hour 6 minutes. That worst run is the one you go and compare.

 Root cause analysis for one Snowflake workload: a Runs Cost chart over a 28 day window with the workload name blurred out. Header stats read 22m 54s average runtime, 1h 6m max, 31 total runs, 0.97 success ratio and $2.27 average cost, and cost in blue is plotted against run time in purple on the same axes. 

Each point on this chart is one run. When the run's makeup changes, the chart flags that point as changed. That flag is the task-count cause showing up before you even compare two runs.

 The same Runs Cost chart with 50 runs plotted, cost in blue against run time in purple. A hover card on the 18 Aug run shows its cost at $7.37 and its run time at 51m 37s, and a red-outlined Run has been changed flag marks that the run's definition shifted since the run before it. 

## Compare Two Runs to Find Out What Changed

The platform's AI compares two runs of the same workload and names the root cause of a spike or a drop. It comes back with one of three things:

| Cause | What it means |
| --- | --- |
| **The warehouse** | The warehouse this workload ran on changed. |
| **The task count** | The workload ran a different number of tasks this time. |
| **The code** | The code behind the workload changed. |

Three causes will not explain every incident. They do cover the ones your runbook can act on, and the rest usually trace back to one of them. Every workload type goes through the same three checks, whether it is a dbt model or a Streamlit app.

When the warehouse is the cause, you get more than a direction to look in. You get the query's lineage, and a written cause. Here that cause is 202.23 GB spilled to remote storage because the warehouse was sized Small. The recommendation comes with it. Run the query on a larger size, or split it into smaller chunks.

 A query lineage graph with two source steps feeding an inner join and a filter into a downstream model, beside a query\_with\_remote\_spillage panel reporting 202.23 GB spilled to remote storage, attributing it to a warehouse configured as Small, and recommending a larger size or splitting the query into smaller chunks. 

## Send the Cause to Jira, Linear, or an Agentic IDE

Once the cause has a name, it stops being an investigation and becomes work. From the opportunity you send it out as a Jira or Linear ticket, or open it in an agentic IDE with the prompt already written.

 The Code tab of a query page showing a CREATE OR REPLACE TABLE statement, with the Opportunities panel below it. On the create\_or\_replace\_table opportunity the Actions menu is open, listing Create Ticket and Open in IDE. 

You choose where the work lands and who owns it. The platform files against Jira or Linear through the Datamate that holds that integration. The ticket reaches the team that already runs on it. Here only Jira is connected.

 The Create Ticket dialog for the create\_or\_replace\_table opportunity. The Platform field is set to Jira, and a Select Datamate dropdown lists the account's Datamates, including a Jira integration Datamate. 

What matters is what travels with the ticket. It carries the opportunity, the resource and the recommended fix. Whoever picks it up does not have to start by working out what went wrong. If you would rather send it yourself, Studio opens with the prompt already written, and the Datamate already selected.

 The Studio assistant opened from Create Ticket, its message box pre-populated with a prompt that reads Help me create a Jira ticket with the below details, followed by the create\_or\_replace\_table optimization and its resource id, with the Jira integration Datamate already selected below the box. 

## What You Get Instead of an Hour of Log Reading

-   **One place for every workload.** dbt models, Tableau workloads, notebooks, stored procedures and Streamlit apps. Each keeps its own run history.
-   **A named cause instead of a theory.** The warehouse, the task count, or the code.
-   **The query that got expensive.** Every run lists the child queries that ran inside it, so the finding points at one query and not at the whole job.
-   **A ticket someone can pick up.** Jira, Linear, or an agentic IDE. The opportunity, the resource and the fix are already written into the prompt.

Proof

On the workload above, one run took 1 hour 6 minutes against a 22 minute 54 second average. The AI named one cause: **202.23 GB spilled to remote storage** on a Small warehouse. You get one query, one reason and one recommendation, rather than a cost line that went up and a shortlist of suspects.

For the wider Snowflake cost picture around this, see [Altimate for Snowflake](https://altimate.ai/use-cases/altimate-for-snowflake).

### Talk to us about your warehouse

[Book a 30-min demo →](https://calendly.com/d/ctnv-rbc-yr3/altimate-ai-overview) 

## Frequently Asked Questions

Which workloads does the root cause analysis read?

What exactly does the AI compare between two runs?

Why not just do this in each tool separately?

What does this need from me to work on dbt?

What do I have to do before I can compare Tableau refreshes?

What if the spike is inside a notebook or a stored procedure?

How does this relate to tracking one query over time?

Where is this documented?

On this page

-   Root Cause Analysis Starts with Every Snowflake Workload Run 
-   Compare Two Runs to Find Out What Changed 
-   Send the Cause to Jira, Linear, or an Agentic IDE 
-   What You Get Instead of an Hour of Log Reading 

## Related Resources

Enterprise Platform Track Snowflake Query Cost Over Time, Run by Run

https://altimate.ai/product-highlights/snowflake-query-cost-over-time

Enterprise Platform Snowflake Cost Analysis in Plain English, with AI That Cites Every Number

https://altimate.ai/product-highlights/snowflake-cost-analysis-ai-cited-answers

Enterprise Platform Attribute Snowflake Cost to the Team That Owns It

https://altimate.ai/product-highlights/snowflake-cost-alerts-by-team

Help Doc AI Cost Analysis (DataPilot)

https://help.altimate.ai/platform/summary/datapilot-analysis/
