Data warehouse auto suspend: the setting that decides half your bill

Quick answer

Auto suspend stops a warehouse after a period of inactivity so idle minutes stop billing. Idle time is often 30 to 60 percent of total warehouse hours in teams that leave the default in place. For scheduled transformation warehouses set auto suspend to 60 seconds, since the next job is minutes away anyway. For interactive BI warehouses use 120 to 300 seconds so the result cache and warm data cache survive between user clicks. Never disable auto suspend. Every resume carries a 60 second minimum billing charge, so suspending too aggressively under a chatty dashboard can cost more than it saves.

A warehouse that is running but doing nothing bills exactly the same as one working at full tilt. That is the whole problem. Auto suspend is a single integer setting, it takes ten seconds to change, and in most accounts it is worth more than every query optimization the team will do that quarter. It is also routinely left at a default nobody chose deliberately, or worse, disabled by someone who got tired of waiting for a resume.

What idle time actually costs

Setup	Billed hours/day	Credits/day (Medium)	Monthly at $3/credit
Auto suspend off, 24/7	24	96	$8,640
Auto suspend 10 min, business hours usage	~11	44	$3,960
Auto suspend 60 s, same usage	~6.5	26	$2,340

The same Medium warehouse, the same queries, the same users. Moving from a warehouse left running to one that suspends after a minute cuts the bill by about 73 percent. Nothing else in the platform offers that return for that little effort. And the 24/7 row is not hypothetical: a warehouse created for a one off migration and never suspended is one of the most common findings in a Snowflake cost review.

The cost of suspending too fast

There are two real penalties. First, every resume bills a minimum of 60 seconds. On a Medium at 4 credits per hour that is about 0.067 credits, roughly 20 cents. If a dashboard polls every 30 seconds and the warehouse suspends after 60, you will pay that minimum thousands of times a day. Second, suspending drops the warehouse local data cache. The next query has to re read from remote storage, which can double or triple its runtime. The result cache in the cloud services layer survives suspension and is free for 24 hours on identical queries, but the local cache does not.

So the decision is not "suspend as fast as possible". It is "suspend just after the gap between queries becomes longer than the resume penalty is worth".

Settings by workload

Workload	Auto suspend	Reasoning
Scheduled ELT and transformations	60 seconds	Next run is minutes or hours away, cache is useless by then
Interactive BI and dashboards	120 to 300 seconds	Users click in bursts, keep the local cache warm
Ad hoc analyst exploration	60 to 120 seconds	Long thinking gaps between queries
Continuous ingestion or serving	300 seconds or keep warm	Resume minimums would dominate
Development and sandbox	60 seconds	Usage is sporadic and unpredictable

Also set auto resume on so a suspended warehouse wakes on the next query. Disabling auto resume to save money just moves the cost onto humans waiting for someone to flip a switch.

Finding the idle time you already pay for

Query the warehouse metering history and compare credits consumed against the sum of query execution seconds for the same warehouse and hour. The gap is idle billing. A warehouse showing 60 credits consumed in a day against 12 credit hours of actual query execution is 80 percent idle, which on a Large at $3 per credit is about $144 a day, $4,300 a month, of pure waste. Do this once per warehouse and rank by absolute dollars, not by percentage, so you fix the expensive ones first.

Same principle, other platforms

One caveat on measurement: a warehouse showing high idle time may be serving a workload that genuinely needs to stay warm, such as a customer facing query path where a cold start is visible to end users. Before tightening a setting, check whether anyone is paying for that warmth in latency terms, then decide deliberately rather than optimizing the number for its own sake.

The idea generalizes. Serverless warehouse tiers and SQL endpoints on other platforms carry their own idle timeouts, usually defaulting to 10 minutes, and a SQL endpoint left at that default across five environments burns real money overnight. Managed Spark clusters have termination timeouts that do the same job, and an interactive cluster left alive on a handful of large instances can cost $30 to $100 a day doing nothing. The pattern is identical to idle non production environmentseverywhere: compute that is provisioned and awake but unused.

Codify the setting rather than clicking it. Warehouse and endpoint definitions belong in Terraform alongside the rest of the platform, which means the suspension policy is reviewable, diffable, and consistent across environments. C3X prices that Terraform against the resource catalog in the pull request, so the cost consequence of an infrastructure change shows up before the month does.

FAQ

What is the best auto suspend setting?

It depends on the workload. Use 60 seconds for scheduled transformation warehouses where the next job is minutes away, and 120 to 300 seconds for interactive BI where users click in bursts and the warm local cache matters. Continuous serving workloads may justify 300 seconds or staying warm, because resume minimums would otherwise dominate the bill.

How much does idle warehouse time cost?

A Medium warehouse left running 24/7 burns 96 credits a day, about $8,640 a month at $3 per credit. The same warehouse suspending after 60 seconds with normal business hours usage costs roughly $2,340. That is around a 73 percent reduction from one setting, with no change to queries, users, or results.

Does suspending a warehouse too often cost more?

It can. Every resume bills a minimum of 60 seconds, roughly 20 cents on a Medium, and suspension clears the warehouse local data cache so the next query re reads from remote storage. A dashboard polling every 30 seconds against a warehouse that suspends after 60 pays that minimum thousands of times a day.

Does the query result cache survive suspension?

Yes. The result cache lives in the cloud services layer, persists for 24 hours, and serves identical queries for free even after the warehouse suspends. The warehouse local data cache does not survive, so the first query after a resume may run noticeably slower while it re reads data from remote storage.

How do I measure idle warehouse billing?

Compare credits consumed per warehouse per hour from metering history against the summed query execution time for the same window. The difference is idle billing. Rank warehouses by absolute dollars wasted rather than by percentage so the biggest savings come first, since 80 percent idle on an X-Small matters far less than 40 percent idle on an X-Large.

Should auto suspend settings live in Terraform?

Yes. Defining warehouses, endpoints, and cluster termination timeouts as code makes the suspension policy reviewable and consistent across environments, instead of a value someone changed in a UI months ago. C3X prices the Terraform managed platform infrastructure in the pull request so cost consequences are visible at review time.

What to do next

Stop paying for idle compute. C3X prices your Terraform resources before they run. Start with the quickstart.