Auto-Suspend and Auto-Resume Fundamentals
AUTO_SUSPEND specifies how many seconds a warehouse can sit idle, with no queries running, before Snowflake automatically suspends it and stops billing credits. AUTO_RESUME, when enabled, automatically restarts a suspended warehouse the instant a new query is submitted against it, typically within one to two seconds, so users rarely notice the warehouse was ever off. Together these two settings mean you don't need a human, or even a script, watching over a warehouse's lifecycle; a warehouse configured with AUTO_SUSPEND=60 and AUTO_RESUME=TRUE will spin down within a minute of the last query and silently spin back up the moment it's needed again.
Cricket analogy: It's like floodlights at a practice net that switch off automatically after ten minutes of no motion detected, and flick back on the instant a bowler walks in for their next set, with nobody needing to flip a switch either way.
Choosing an Auto-Suspend Interval
The right AUTO_SUSPEND value depends on the workload's query pattern. A short interval like 60 seconds minimizes wasted credits for bursty, infrequent workloads such as an analyst running occasional ad hoc queries, but it can add repeated resume latency and the 60-second minimum billing charge if queries arrive every couple of minutes. A longer interval, such as 10 or 15 minutes, suits workloads with frequent, closely-spaced queries, like a dashboard refreshing every few minutes, because it avoids constantly suspending and resuming (and re-billing the minimum) between each query, keeping the warehouse warm.
Cricket analogy: Choosing the interval is like deciding how long to leave the covers off between rain showers: pull them on quickly for a light, infrequent drizzle, but leave the ground open if you expect play to resume again within minutes.
Interaction With Multi-Cluster Auto-Scaling
Auto-suspend applies at the cluster level within a multi-cluster warehouse: as demand drops, Snowflake shuts down individual extra clusters independently, eventually settling back to MIN_CLUSTER_COUNT, and if all activity stops, the remaining base cluster(s) suspend according to AUTO_SUSPEND just like a single-cluster warehouse would. This means auto-scaling and auto-suspend work together across the full lifecycle of demand: clusters are added as concurrency rises, removed one by one as it falls, and the warehouse fully powers down when nothing is running, giving you elastic cost control at both the concurrency and idle-time dimensions.
Cricket analogy: It's like a ground adding extra security staff as the crowd builds before a final, releasing them gate by gate as fans head home, and finally locking up entirely once the ground is empty for the night.
-- Tune auto-suspend for a bursty ad hoc analyst warehouse
ALTER WAREHOUSE analyst_wh SET
AUTO_SUSPEND = 60
AUTO_RESUME = TRUE;
-- Tune a frequently-refreshed dashboard warehouse to stay warm longer
ALTER WAREHOUSE bi_dashboard_wh SET
AUTO_SUSPEND = 600
AUTO_RESUME = TRUE
MIN_CLUSTER_COUNT = 1
MAX_CLUSTER_COUNT = 5
SCALING_POLICY = 'STANDARD';
-- Check whether a warehouse is currently running or suspended
SHOW WAREHOUSES LIKE 'bi_dashboard_wh';AUTO_RESUME latency for a suspended warehouse is typically just one to two seconds for standard warehouses, which is why it's almost always safe to leave AUTO_SUSPEND on a fairly short interval for intermittent workloads rather than paying for idle compute just to avoid a brief resume delay.
Setting AUTO_SUSPEND too low for a workload with queries every 90-120 seconds can actually increase cost: each resume triggers the 60-second minimum billing charge, so a warehouse that suspends and resumes every couple of minutes may cost more in aggregate than one that simply stayed running with a longer suspend interval.
- AUTO_SUSPEND idles out a warehouse after N seconds of no queries, stopping credit billing.
- AUTO_RESUME automatically restarts a suspended warehouse within one to two seconds of a new query.
- Short suspend intervals suit bursty, infrequent workloads; longer intervals suit frequent, closely-spaced queries.
- Auto-suspend applies at the cluster level within multi-cluster warehouses as extra clusters wind down.
- Auto-scaling and auto-suspend together manage cost across both concurrency and idle-time dimensions.
- Very short suspend intervals on frequent workloads can increase cost due to repeated 60-second minimum billing.
- SHOW WAREHOUSES lets you check a warehouse's current running/suspended state at a glance.
Practice what you learned
1. What does AUTO_SUSPEND control?
2. Roughly how long does AUTO_RESUME typically take to bring a suspended standard warehouse back online?
3. Why might a very short AUTO_SUSPEND interval increase cost for a workload with queries every 90 seconds?
4. In a multi-cluster warehouse, how does auto-suspend behavior work?
5. Which workload pattern is best suited to a longer AUTO_SUSPEND interval?
Was this page helpful?
You May Also Like
Virtual Warehouses
Learn how Snowflake's virtual warehouses provide independently scalable compute clusters that are fully decoupled from storage.
Multi-Cluster Warehouses
Understand how multi-cluster warehouses handle high concurrency by automatically adding and removing compute clusters.
Query Performance and Caching
Explore Snowflake's layered caching model, including result cache, local disk cache, and metadata cache, and how each speeds up repeated queries.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics
ProgrammingPowerShell Study Notes
Programming · 30 topics