Credits jumped overnight and nobody was running anything. This is a short investigation if you go straight to the metering history, and a long one if you start in the Snowsight cost dashboard.
Credits are time multiplied by size
The mental model that makes this fast: a warehouse consumes credits for every second it is running, at a rate set by its size. An X-Small burns 1 credit per hour, and each size step doubles it — so a 4X-Large burns 128.
Two consequences follow, and both are counter-intuitive.
A single query on a large warehouse can outspend thousands of small ones. Query count is nearly irrelevant; warehouse-hours are everything.
A warehouse with no queries running can still cost you. If it has not suspended, it is billing. This is the single most common cause of overnight spikes.
Find the warehouse and the hour
Start with metering history rather than the cost dashboard, because it is hourly and attributes cleanly:
SELECT warehouse_name,
DATE_TRUNC('hour', start_time) AS hour,
SUM(credits_used) AS credits
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time >= DATEADD('day', -3, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY credits DESC
LIMIT 20;
This gives you a warehouse and a specific hour, which is all you need to narrow the next query. Note that ACCOUNT_USAGE views have latency of up to a few hours — if the spike is very recent, use the INFORMATION_SCHEMA equivalents instead.
Find what was running
Join query history for that warehouse and window, sorted by execution time rather than by count:
SELECT query_id, user_name, warehouse_size,
total_elapsed_time / 1000 AS seconds,
bytes_spilled_to_remote_storage,
LEFT(query_text, 120) AS query
FROM snowflake.account_usage.query_history
WHERE warehouse_name = 'YOUR_WAREHOUSE'
AND start_time BETWEEN 'START' AND 'END'
ORDER BY total_elapsed_time DESC
LIMIT 20;
Three findings are common at this point.
One very long query. A missing filter, an accidental cross join, or a query against an unpartitioned table.
Remote spilling. A non-zero bytes_spilled_to_remote_storage means the warehouse ran out of memory and started using remote storage, which is dramatically slower and therefore dramatically more expensive. Spilling turns a two-minute query into a two-hour one.
Nothing at all. No queries in the window, but credits consumed. That is the auto-suspend problem below.
When credits burn with no queries
If metering shows consumption and query history shows nothing, the warehouse was running idle. Three causes:
Auto-suspend set too high. A warehouse with a ten-minute suspend and a query arriving every nine minutes never suspends. It bills continuously while appearing lightly used.
Auto-suspend disabled. Sometimes set deliberately to avoid cold starts and then forgotten.
A session holding it open. A BI tool, a notebook, or a connection pool keeping the warehouse alive without issuing meaningful work.
Check the setting directly:
SHOW WAREHOUSES;
Look at auto_suspend and auto_resume. For most workloads 60 seconds is a reasonable suspend; the cold-start cost is small relative to idle credits.
Why it happened overnight specifically
Overnight spikes have a narrower set of causes, which is helpful.
Scheduled jobs and ELT pipelines run then, and a failure that triggers retries will loop unattended for hours. A task that normally takes twenty minutes and instead runs until morning is the classic.
Automatic clustering and materialised view maintenance also run in the background and consume credits against serverless rather than warehouse metering — check AUTOMATIC_CLUSTERING_HISTORY if warehouse metering does not account for the whole increase.
And a scheduled job that grew past a memory threshold will begin spilling, which converts a predictable nightly cost into a multiple of it without any change to the job itself.
Preventing the repeat
Set auto-suspend to 60 seconds on everything except warehouses with a demonstrated cold-start problem.
Use resource monitors with a credit quota and a suspend action. This is Snowflake's only hard stop, and without one there is no ceiling on a runaway job.
Separate warehouses by workload. ELT, BI and ad-hoc querying on one warehouse means you cannot attribute credits, and sizing it for the heaviest workload overpays for the lightest.
Cap size for ad-hoc use. Most accidental spikes come from someone running an exploratory query on a warehouse sized for a nightly batch.
Alert on daily credits against a baseline. A monthly credit budget will not tell you that a warehouse started running continuously three days ago. StackSpend tracks Snowflake credit consumption daily and flags deviation per warehouse, which is the signal that turns this runbook into a same-day fix.
FAQ
How do I find which Snowflake warehouse used the most credits?
Query SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY grouped by warehouse and hour. It attributes credits directly and is more precise than the Snowsight cost view for narrowing a spike to a window.
Why is my Snowflake warehouse consuming credits with no queries running?
It has not suspended. Either auto-suspend is disabled, set too high for the query arrival pattern, or a client session is holding the warehouse open. Check SHOW WAREHOUSES for the auto_suspend value.
What does bytes spilled to remote storage mean for cost?
The query exceeded warehouse memory and fell back to remote storage, which is orders of magnitude slower. Since credits accrue per second, spilling can multiply the cost of a single query many times over. It usually means the warehouse is undersized for that query, not oversized.
Will a resource monitor stop a runaway Snowflake query?
Yes, if configured with a suspend action. A resource monitor with a credit quota is the only hard ceiling Snowflake provides — notifications alone will not stop consumption.
