SELECT warehouse_name,
       warehouse_size,
       COUNT(*) AS queries,
       ROUND(MEDIAN(bytes_scanned) / POWER(1024, 3), 3) AS median_gb_scanned,
       ROUND(APPROX_PERCENTILE(bytes_scanned, 0.9) / POWER(1024, 3), 3) AS p90_gb_scanned,
       ROUND(MEDIAN(execution_time) / 1000, 1) AS median_exec_s,
       SUM(IFF(bytes_spilled_to_local_storage > 0, 1, 0)) AS spilling_queries
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -14, CURRENT_TIMESTAMP())
  AND warehouse_size IS NOT NULL
  AND execution_status = 'SUCCESS'
GROUP BY 1, 2
ORDER BY queries DESC;

How to read it

• Large or bigger warehouse, p90 under ~1 GB scanned, median runtime a few seconds: most queries are too small to use the compute. Try one size down.
• No spilling queries: memory isn't the constraint, which makes downsizing lower risk.
• Spilling on the current size: leave it, or fix the spilling queries before resizing.

What to do about it

1. Drop one size on a single candidate: ALTER WAREHOUSE <name> SET WAREHOUSE_SIZE = 'MEDIUM';
2. Re-run this query after a few days and compare median runtime. If it barely moved, you just halved that warehouse's credit rate.
3. Keep a separate larger warehouse for the few heavy jobs instead of sizing everything for them.

Want a quick start first? The free Snowflake Slow Query Triage kit has five read-only queries like this. The Snowflake Query Performance Tuning Kit adds pruning, spilling, queueing and idle-warehouse diagnostics with a guide to every result. Running cost, performance and security reviews together? The Snowflake Complete Toolkit bundles all three kits (32 read-only SQL files) for $69.

WITH billed AS (
  SELECT warehouse_name,
         SUM(credits_used_compute) AS credits_billed
  FROM snowflake.account_usage.warehouse_metering_history
  WHERE start_time >= DATEADD(day, -14, CURRENT_TIMESTAMP())
  GROUP BY 1
),
busy AS (
  SELECT warehouse_name,
         ROUND(SUM(execution_time) / 3.6e6, 2) AS query_hours,
         COUNT(*) AS queries
  FROM snowflake.account_usage.query_history
  WHERE start_time >= DATEADD(day, -14, CURRENT_TIMESTAMP())
    AND warehouse_name IS NOT NULL
  GROUP BY 1
)
SELECT b.warehouse_name,
       ROUND(b.credits_billed, 2) AS credits_billed,
       COALESCE(q.query_hours, 0) AS query_hours,
       COALESCE(q.queries, 0)     AS queries
FROM billed b
LEFT JOIN busy q USING (warehouse_name)
ORDER BY credits_billed DESC;

Then check each warehouse's current setting:

SHOW WAREHOUSES;
-- look at the auto_suspend column (seconds)

How to read it

• Many credits, few query hours: the warehouse sits idle while billing. Look at its auto_suspend value first.
• auto_suspend of 600 or more: each wake-up can bill ten idle minutes. 60 seconds is a sensible default for most BI and ad-hoc warehouses.
• Lots of small queries all day: something is polling. Find it in query_history by user or client and slow it down.

What to do about it

1. Set ALTER WAREHOUSE <name> SET AUTO_SUSPEND = 60; on the worst offenders (test on one first).
2. Re-run the comparison a week later.
3. Move tiny scheduled jobs onto one shared small warehouse instead of keeping several awake.

Want a quick start first? The free Snowflake Slow Query Triage kit has five read-only queries like this. The Snowflake Query Performance Tuning Kit adds warehouse sizing, pruning, spilling and queueing diagnostics with a guide to every result.

SELECT query_parameterized_hash,
       ANY_VALUE(LEFT(query_text, 200))           AS sample_text,
       ANY_VALUE(warehouse_name)                  AS warehouse,
       COUNT(*)                                   AS runs,
       ROUND(SUM(total_elapsed_time) / 3.6e6, 2)  AS total_hours,
       ROUND(AVG(total_elapsed_time) / 1000, 1)   AS avg_seconds,
       ROUND(AVG(bytes_scanned) / POWER(1024, 3), 2) AS avg_gb_scanned
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -14, CURRENT_TIMESTAMP())
  AND warehouse_name IS NOT NULL
  AND execution_status = 'SUCCESS'
GROUP BY 1
ORDER BY total_hours DESC
LIMIT 25;

How to read it

• High runs, low avg_seconds: a dashboard or job firing far more often than anyone needs. Cut the refresh rate or let the result cache serve it.
• Low runs, high avg_seconds: one heavy job. Check partition pruning and spilling on its query profile.
• High avg_gb_scanned: the query reads most of a big table. Add a filter on the clustering column or select fewer columns.

What to do about it

1. Fix the top three patterns first. They usually account for most of the hours.
2. Re-run the query a week later and compare total_hours.
3. Only then think about warehouse size.

The Snowflake Query Performance Tuning Kit includes this script plus 9 other read-only diagnostics (pruning, spilling, queueing, warehouse sizing) with a guide to what each result means.

SELECT warehouse_name,
       DATE_TRUNC('hour', start_time)         AS hour_start,
       ROUND(AVG(avg_running), 2)             AS avg_running,
       ROUND(AVG(avg_queued_load), 2)         AS avg_queued_load,
       ROUND(AVG(avg_queued_provisioning), 2) AS avg_queued_provisioning,
       ROUND(AVG(avg_blocked), 2)             AS avg_blocked
FROM snowflake.account_usage.warehouse_load_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
GROUP BY 1, 2
HAVING AVG(avg_queued_load) > 0 OR AVG(avg_blocked) > 0
ORDER BY avg_queued_load DESC
LIMIT 100;

How to read it

• avg_queued_load > 0 means queries waited because the warehouse was busy. If it clusters at the same hours every day, you have a concurrency problem.
• avg_queued_provisioning is time spent waiting for compute to start or resize. Frequent auto-suspend plus bursty traffic causes this.
• avg_blocked is waiting on locks, usually concurrent MERGE or UPDATE jobs hitting the same table.

What to do about it

1. Queueing at peak, little spilling: a bigger warehouse won't help much. Raise MAX_CLUSTER_COUNT (multi-cluster, Enterprise edition) or move BI and ELT onto separate warehouses.
2. Provisioning waits: lengthen AUTO_SUSPEND slightly on the busiest warehouse so it isn't cold-starting every few minutes.
3. Blocked time: serialize the DML jobs that touch the same tables.
4. No queueing and low load: the warehouse may be oversized. Try one size down and compare elapsed times.

The Snowflake Query Performance Tuning Kit includes a second part of this script that gives every warehouse a sizing verdict (concurrency, memory, or possibly oversized) from 14 days of query history, plus 9 other read-only diagnostics.

SELECT query_id, warehouse_name, partitions_scanned, partitions_total,
       ROUND(100 * partitions_scanned / NULLIF(partitions_total, 0), 1) AS pct_scanned,
       ROUND(bytes_scanned / POWER(1024, 3), 2) AS gb_scanned,
       ROUND(total_elapsed_time / 1000, 1) AS elapsed_s,
       LEFT(query_text, 300) AS query_snippet
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
  AND UPPER(execution_status) = 'SUCCESS'
  AND query_type = 'SELECT'
  AND partitions_total >= 1000
  AND partitions_scanned / NULLIF(partitions_total, 0) > 0.8
ORDER BY partitions_scanned DESC
LIMIT 50;

A pct_scanned near 100 on a big table with a selective WHERE clause is the signal. Full scans are fine for genuine full-table jobs, so check the query text.

The most common fix: filter directly on the column the data arrives in order of, and don't wrap it in a function.

WHERE TO_DATE(event_ts) = '2026-01-01'                         -- prunes poorly
WHERE event_ts >= '2026-01-01' AND event_ts < '2026-01-02'     -- prunes well

Also filter the fact table directly instead of only through a join to a dimension. If the natural filter column isn't how the data was loaded, consider a clustering key or search optimization.

The Snowflake Query Performance Tuning Kit includes a per-table version of this check (via ACCESS_HISTORY) plus 9 other diagnostic scripts.

SELECT query_id, warehouse_name, warehouse_size,
       ROUND(total_elapsed_time / 1000, 1) AS elapsed_s,
       ROUND(bytes_scanned / POWER(1024, 3), 2) AS gb_scanned,
       ROUND(bytes_spilled_to_local_storage / POWER(1024, 3), 2) AS gb_spilled_local,
       ROUND(bytes_spilled_to_remote_storage / POWER(1024, 3), 2) AS gb_spilled_remote,
       ROUND((bytes_spilled_to_local_storage + bytes_spilled_to_remote_storage)
             / NULLIF(bytes_scanned, 0), 2) AS spill_ratio,
       LEFT(query_text, 300) AS query_snippet
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
  AND (bytes_spilled_to_local_storage > 0 OR bytes_spilled_to_remote_storage > 0)
ORDER BY bytes_spilled_to_remote_storage DESC, bytes_spilled_to_local_storage DESC
LIMIT 50;

How to read it: spill_ratio is GB spilled divided by GB scanned. A ratio well above 1 usually means a join or aggregation is multiplying rows, not that the warehouse is too small.

Fix it in this order:

1. Reduce the data: filter earlier, select fewer columns, pre-aggregate before joining, fix accidental many-to-many joins.
2. Drop unnecessary ORDER BY / DISTINCT / window functions over the full data set.
3. If the query is already lean, try the next warehouse size up and re-measure. If the remote spill disappears, the bigger size is often cheaper overall.
4. For memory-heavy workloads, consider a Snowpark-optimized warehouse.

This is one of 10 diagnostic scripts in the Snowflake Query Performance Tuning Kit, which also covers pruning, queueing, cache hit rates, exploding joins and clustering candidates. All read-only.

Free download

Free download: grab 5 more triage queries in the free Snowflake Slow Query Triage kit: https://thyneventures.gumroad.com/l/snowflake-slow-query-triage . Want the full playbook? The Snowflake Query Performance Tuning Kit is 30% off with code LAUNCH30 until Thu Oct 29: https://thyneventures.gumroad.com/l/rvmloh

The good news is that Snowflake already records why each query was slow. It's all in SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY. Here are three read-only queries I use to separate "needs a bigger warehouse" from "needs a better query".

You need a role with IMPORTED PRIVILEGES on the SNOWFLAKE database. QUERY_HISTORY can lag real time by up to about 45 minutes, and all times in it are in milliseconds.

1. Where does the time actually go?

Every query's elapsed time breaks down into compile, queue, lock wait and execution. This query shows the 25 slowest queries of the week and names the phase that dominated.

SELECT query_id,
       warehouse_name,
       warehouse_size,
       ROUND(total_elapsed_time / 1000, 1) AS elapsed_s,
       ROUND(compilation_time / 1000, 1)   AS compile_s,
       ROUND((queued_provisioning_time + queued_repair_time
              + queued_overload_time) / 1000, 1) AS queued_s,
       ROUND(transaction_blocked_time / 1000, 1) AS lock_wait_s,
       ROUND(execution_time / 1000, 1)     AS exec_s,
       CASE GREATEST(compilation_time,
                     queued_provisioning_time + queued_repair_time + queued_overload_time,
                     transaction_blocked_time, execution_time)
            WHEN execution_time   THEN 'EXECUTION'
            WHEN compilation_time THEN 'COMPILE'
            WHEN transaction_blocked_time THEN 'LOCK_WAIT'
            ELSE 'QUEUE'
       END AS dominant_phase,
       LEFT(query_text, 200) AS query_snippet
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
  AND UPPER(execution_status) = 'SUCCESS'
  AND warehouse_name IS NOT NULL
ORDER BY total_elapsed_time DESC
LIMIT 25;

How to read it:

• QUEUE means the warehouse was full. That's a concurrency problem, so think multi-cluster or separate warehouses, not a bigger size.
• COMPILE means the SQL is hard to plan: giant generated statements, deep view stacks, or huge IN lists. Warehouse size is irrelevant here.
• LOCK_WAIT means concurrent DML on the same table. Serialize those jobs.
• EXECUTION is the only case where the next two queries (and possibly a bigger warehouse) come in.

2. Is it spilling?

When a join or aggregation doesn't fit in memory, Snowflake spills to local disk and then to remote storage. Remote spilling is where queries go from seconds to many minutes.

SELECT query_id,
       warehouse_name,
       warehouse_size,
       ROUND(total_elapsed_time / 1000, 1)                        AS elapsed_s,
       ROUND(bytes_scanned / POWER(1024, 3), 2)                   AS gb_scanned,
       ROUND(bytes_spilled_to_local_storage / POWER(1024, 3), 2)  AS gb_spilled_local,
       ROUND(bytes_spilled_to_remote_storage / POWER(1024, 3), 2) AS gb_spilled_remote,
       LEFT(query_text, 200)                                      AS query_snippet
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
  AND (bytes_spilled_to_local_storage > 0 OR bytes_spilled_to_remote_storage > 0)
ORDER BY bytes_spilled_to_remote_storage DESC, bytes_spilled_to_local_storage DESC
LIMIT 25;

How to read it: compare gb_spilled_* with gb_scanned. If a query spills far more than it scanned, something is multiplying rows. That's usually a join on a non-unique key, so check the join before you touch the warehouse. If the query is already lean, try one size up and re-measure. When remote spilling disappears, the larger size often costs less in total because it finishes so much faster.

3. Is it pruning?

Snowflake stores tables in micro-partitions and skips the ones a filter rules out. That's pruning, and it's the single biggest performance lever you have. This query finds SELECTs on large tables that read more than 80% of the partitions anyway.

SELECT query_id,
       warehouse_name,
       partitions_scanned,
       partitions_total,
       ROUND(100 * partitions_scanned / NULLIF(partitions_total, 0), 1) AS pct_scanned,
       ROUND(total_elapsed_time / 1000, 1) AS elapsed_s,
       LEFT(query_text, 200) AS query_snippet
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
  AND query_type = 'SELECT'
  AND partitions_total >= 1000
  AND partitions_scanned / NULLIF(partitions_total, 0) > 0.8
ORDER BY partitions_scanned DESC
LIMIT 25;

How to read it: read the WHERE clause of each query. The classic culprit is wrapping the filter column in a function:

-- prunes poorly
WHERE TO_DATE(event_ts) = '2026-10-01'
-- prunes well
WHERE event_ts >= '2026-10-01' AND event_ts < '2026-10-02'

If the filter is already clean and the table is large and read far more often than it's written, the table may be a candidate for a clustering key.

What these queries can't tell you

QUERY_HISTORY reports one row per query, so it can't tell you which join exploded or which table in a five-way join failed to prune. For that, open the Query Profile in Snowsight, or run GET_QUERY_OPERATOR_STATS('<query_id>'). It returns input and output rows for every operator, and it works for any query from the last 14 days. Use the three queries above to decide where to look, then use the profile to find the exact operator.

Tune patterns, not single queries

Once you know what kind of slow you're dealing with, group by query_parameterized_hash instead of query_id. A 15-second dashboard query that runs 4,000 times a day usually matters more than one 30-minute monster. Fix the top three patterns, tag them with QUERY_TAG, and re-run these queries a week later to confirm the improvement.

Disclosure: I sell a paid kit built on these ideas. The Snowflake Query Performance Tuning Kit has 10 read-only scripts that also cover queueing and warehouse sizing, cache hit rates, compile-heavy patterns, exploding joins (with per-join row counts), clustering candidates, Query Acceleration eligibility and failed/timed-out queries, plus a fix playbook: https://thyneventures.gumroad.com/l/rvmloh. The three queries above are free to use however you like. Not affiliated with Snowflake Inc.

Free download

Free download: grab 5 more triage queries in the free Snowflake Slow Query Triage kit: https://thyneventures.gumroad.com/l/snowflake-slow-query-triage . Want the full playbook? The Snowflake Query Performance Tuning Kit is 30% off with code LAUNCH30 until Thu Oct 29: https://thyneventures.gumroad.com/l/rvmloh