Snowflake bills in credits, and credits are driven mostly by warehouse compute time. So almost every Snowflake cost spike traces back to a warehouse running more than it should.
What makes a warehouse spike credits
- Resizing. A warehouse bumped from Small to Large quadruples credit consumption per second — sometimes done to fix a slow query and never reverted.
- Missed auto-suspend. A warehouse with auto-suspend set too high (or disabled) stays warm between queries, burning credits while idle.
- Heavier query patterns. A dashboard refresh, a new dbt model, reverse ETL, or analyst queries that scan more data keep the warehouse busy longer.
- Scheduled job creep. Experiments that move from ad hoc to scheduled jobs add steady, recurring runtime.
Finding the driver fast
Break credit usage down by warehouse, then by query tag and user, and compare warehouse runtime and queue time against your baseline. The warehouse whose runtime changed slope is your spike. Check its auto-suspend setting and the queries hitting it in the spike window.
Preventing the next one
Tighten auto-suspend, right-size warehouses, and add query budgets for the workloads that drove the spike — then monitor so the next one is a same-day alert.
StackSpend's Snowflake cost monitoring tracks organization usage and credits, breaks spend down by warehouse, and fires anomaly alerts the day warehouse runtime jumps. Forecasting tracks pace against your credit budget.
If your Snowflake bill already spiked, start with why is my Snowflake bill so high.