# Understanding Cost Spikes

URL: https://select.dev/docs/reference/usage-guide/understanding-cost-spikes
Index of all SELECT docs: https://select.dev/docs/llms.txt

> We will walk through how to use SELECT to understand cost spikes in your Snowflake account

[YouTube video](https://youtu.be/6yZTSzGCF0s)

SELECT makes it easy to spot and investigate unexpected cost spikes in your Snowflake account. The high level process is:

1. Use the trend charts on the Home → Dashboard to identify dates with a spike in spend.
2. Pinpoint which services, warehouses, users, or databases contributed to the spike.
3. Use those details to filter down to specific workloads. For example, you can navigate to the Workloads page filtered by date range and warehouse to isolate the source of the spike.

## Identify Spikes Using the Trend Charts

Navigate to **Home → Dashboard** (tab at the top of the screen). In this example, I’ll set the date filter to **Last 90 Days** to surface spikes across a longer timeframe. Here, there’s a clear cost spike from late May to early June:

![SELECT dashboard page reveals a spike in Snowflake cost](https://cdn.sanity.io/images/wn0ylp2c/production/cfb1762bb4f8d9f7b8539ef758ba61e5b23eeba4-1660x729.png)

As I scroll down, I can see spend broken out by category. The first category is **Snowflake Service**, where it becomes immediately clear the spike is in **Compute** spend. Interestingly, once compute spend returned to normal, there was a noticeable spike in **Storage** spend a few days later.

![Analyze cost spikes in SELECT](https://cdn.sanity.io/images/wn0ylp2c/production/cfb1762bb4f8d9f7b8539ef758ba61e5b23eeba4-1660x729.png)

Continuing down the page, we see the spike was entirely driven by the **SYSTEM** user. That suggests the cause could be a task or dynamic table, but let’s keep exploring.

![Analyze cost spikes in SELECT](https://cdn.sanity.io/images/wn0ylp2c/production/45cae020cf769436b70bd83c9cf62981e8fdf9a6-800x392.gif)

We can see from the final chart that TUTORIAL_DB was responsible for the Storage spike.

![Snowflake storage cost by Database in SELECT](https://cdn.sanity.io/images/wn0ylp2c/production/4603db59426fa7d8631197ee6c01bb467bcc01cd-1660x499.png)

Now, let’s find out what happened.

## Drill Down to Resources with the Spike

Let’s figure out what caused the spike in Compute cost. First, filter to the date range where the spike occurred. Then, click the warehouse name in the Warehouse bar chart to jump to the Workloads page filtered by that warehouse and date range.

From there, it quickly becomes clear that a Task called `WEEKLY_REFRESH_DEMO_ORDERS` was responsible for about 90% of the spend on those days.

![Drill down on Snowflake costs spikes in SELECT](https://cdn.sanity.io/images/wn0ylp2c/production/13aee8b17b00d05fb517c199d6254bddfdd61293-800x397.gif)

Click the workload name in the table, then go to the **Cost & Performance** tab. Here, you’ll see the task was running about 300 times per day for a few days, then dropped to once per day. That explains the spike!

![In SELECT, use Cost and Performance tab to analyze any asset that drove a Snowflake cost spike](https://cdn.sanity.io/images/wn0ylp2c/production/b547496cc6f654f92665a1b3e020bca95b0c14c2-1655x929.png)

## Generalizing the Approach

You can take the same approach from any of the “Resources” pages in SELECT: Workloads, Query History, Warehouses, or Storage. You can also follow this process from the Explorer page. The steps are:

1. Identify the spike on a trend chart.
2. Filter to the spike.
3. Drill into the detailed pages by clicking the left column.
4. Analyze the _Cost & Performance_ tab, _Lineage_, and _Insights_.