Snowflake Unexpected Credit Consumption: Tracing the Warehouses and Queries Driving Cost Spikes

Cause 1: AUTO_SUSPEND set too high or not configured. A warehouse with AUTO_SUSPEND=0 (never suspends) or AUTO_SUSPEND set to 60+ minutes continues running and consuming credits long after the last query completes. A single accidental query on a large (XL, 2XL) warehouse can cost 4-16 credits per hour if the warehouse stays running for hours afterward.

Cause 2: AUTO_RESUME triggering for incidental queries. Warehouses with AUTO_RESUME=TRUE restart automatically when any query is submitted. If a monitoring query, a Tableau dashboard auto-refresh, or a Looker scheduled run submits queries to a warehouse at off-hours, the warehouse restarts and runs for the full AUTO_SUSPEND duration even if the query takes 2 seconds.

Cause 3: Full table scan query on a large table. A new analytics query that lacks a WHERE clause filter on a clustered column, or uses a LIKE pattern that cannot leverage clustering metadata, performs a full table scan. On a terabyte-scale table, this can consume 10-100x more credits than a filtered query and may keep the warehouse running for hours.

Cause 4: Snowpipe continuous load with large file volumes. Snowpipe charges credits separately from query warehouses (billed per file loaded using Snowflake's internal resources). A new SQS event trigger that fires on every file write to an S3 bucket, rather than batching files, generates thousands of micro-loads per hour. The per-file overhead accumulates into significant credit consumption that is not visible in warehouse metering.

Cause 5: Multi-cluster warehouse scaling. Warehouses configured for multi-cluster auto-scaling (MIN_CLUSTER_COUNT=1, MAX_CLUSTER_COUNT=4) can scale out to multiple clusters under concurrent query load. Each additional cluster consumes the same credits as the base cluster. A concurrency spike (a batch job + an interactive analytics session hitting the warehouse simultaneously) can double or quadruple the credit consumption rate.

Step 1: Identify which warehouse consumed the credits and when.

SELECT
  warehouse_name,
  SUM(credits_used) AS total_credits,
  MIN(start_time) AS first_activity,
  MAX(end_time) AS last_activity
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
GROUP BY warehouse_name
ORDER BY total_credits DESC;

This shows the top credit consumers over the past 7 days. The warehouse at the top of the list (or a warehouse with anomalously high consumption compared to its baseline) is the starting point.

Step 2: Narrow to the specific time window of the spike.

SELECT
  start_time,
  end_time,
  credits_used,
  credits_used_compute
FROM snowflake.account_usage.warehouse_metering_history
WHERE warehouse_name = '<warehouse-name>'
  AND start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY start_time;

This shows the hourly credit consumption for the warehouse. Identify the hours where consumption was anomalously high.

Step 3: Find the queries that ran during the spike window.

SELECT
  user_name,
  query_text,
  total_elapsed_time / 1000 AS seconds,
  credits_used_cloud_services,
  bytes_scanned,
  rows_produced,
  start_time
FROM snowflake.account_usage.query_history
WHERE warehouse_name = '<warehouse-name>'
  AND start_time >= '<spike-start>'
  AND start_time <= '<spike-end>'
ORDER BY total_elapsed_time DESC
LIMIT 20;

The top results (longest execution time and most bytes scanned) are the most likely causes of the credit spike.

Step 4: Check Snowpipe consumption separately.

SELECT
  pipe_name,
  SUM(credits_used) AS total_credits,
  SUM(files_inserted) AS files_loaded
FROM snowflake.account_usage.pipe_usage_history
WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP())
GROUP BY pipe_name
ORDER BY total_credits DESC;

If Snowpipe consumption is anomalously high for a specific pipe, check the pipe's source stage and event notification configuration.

Fix: Misconfigured AUTO_SUSPEND.

Set AUTO_SUSPEND to 60-120 seconds for interactive warehouses and 300-600 seconds for batch warehouses:

ALTER WAREHOUSE <name> SET AUTO_SUSPEND = 60;

For security-critical environments where credit cost visibility is a compliance concern, set AUTO_SUSPEND to 60 seconds (1 minute) on all warehouses and use APPLICATION-level query queuing to handle burst concurrency rather than keeping warehouses running.

Fix: Scheduled queries keeping warehouses alive.

Identify which scheduled query triggered the warehouse restart:

SELECT query_text, user_name, start_time
FROM snowflake.account_usage.query_history
WHERE warehouse_name = '<warehouse-name>'
  AND start_time >= '<off-hours-window>'
ORDER BY start_time;

For dashboard auto-refresh queries, consider pointing them to a smaller warehouse (XS or S size) that is not shared with heavy batch jobs.

Fix: Full table scan queries.

For queries identified in QUERY_HISTORY with high bytes_scanned values:

1. Check whether the table has a clustering key defined: SHOW TABLES LIKE '<table-name>'.
2. Review the query's WHERE clause for filters that can use clustering metadata.
3. If the table is not clustered and full scans are frequent, evaluate adding a cluster key on the most common filter column.
4. For external tools (Tableau, Looker, dbt), review the generated SQL for missing WHERE clauses or filters that use non-clustering columns.

Fix: Snowpipe over-triggering.

If Snowpipe is loading thousands of small files per hour:

1. Review the S3 event notification trigger. If it fires on every object write (including temp files and metadata files), add an S3 event filter to trigger only on files matching your data format pattern.
2. Consider batching files using an SQS queue with a batch window rather than triggering per-file.
3. Set a Snowpipe credit quota using Snowflake's resource monitor to cap Snowpipe consumption per day.

Resource monitors are the most effective prevention tool for unexpected credit spikes:

CREATE RESOURCE MONITOR <monitor-name>
  WITH CREDIT_QUOTA = 100
  TRIGGERS
    ON 75 PERCENT DO NOTIFY
    ON 90 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

Assign the resource monitor to specific warehouses:

ALTER WAREHOUSE <warehouse-name> SET RESOURCE_MONITOR = <monitor-name>;

For critical production warehouses, use SUSPEND_IMMEDIATE instead of SUSPEND at 100% to stop any running queries and prevent overruns. For analytics warehouses used by interactive users, use NOTIFY at 90% and SUSPEND at 100% so running queries complete before the warehouse is stopped.

Set separate resource monitors per warehouse tier rather than a single account-level monitor, so a batch spike on one warehouse does not consume the quota shared with production warehouses.

Security workloads on Snowflake have distinct credit consumption patterns that differ from standard analytics:

Security log warehouses. SIEM-integrated Snowflake warehouses that run continuous queries against security log tables often have warehouses that never suspend. This is frequently intentional (the SIEM needs continuous access) but should be explicitly documented as an expected cost, not treated as a spike.

Threat hunting sessions. An ad-hoc threat hunting query that scans 90-180 days of security logs across a multi-terabyte table can consume dozens of credits in a single session. These are legitimate but should be run on a dedicated threat hunting warehouse (separate from the production analytics warehouse) with its own resource monitor.

OAuth token audit queries. Automated queries that audit OAuth token usage across SaaS applications, often run as scheduled Snowflake tasks, can generate significant scan volumes if they query unbounded time ranges. Add WHERE clauses that limit the scan to recent data and add an index filter using the token creation timestamp column.

Contact Snowflake Support when:

• WAREHOUSE_METERING_HISTORY shows credit consumption for a warehouse during a time window when no queries appear in QUERY_HISTORY for that warehouse.
• A warehouse consumed credits without any associated user queries (this can indicate a system-initiated operation or a billing anomaly).
• Credits were charged to your account for a Snowflake service (Snowpipe, Automatic Clustering, Materialized View maintenance) in an amount that significantly exceeds what your usage volume would explain.

For a support case, provide: the warehouse name, the specific time window, the WAREHOUSE_METERING_HISTORY output showing the unexplained consumption, and the QUERY_HISTORY output showing no corresponding queries for that window.