Skip to main content
orphan · snowflake

Warehouses with AUTO_SUSPEND disabled or set above 120 seconds

resource types
1
rule IDs covered
1
severity
high

What does ZopNight detect here?

AUTO_SUSPEND left null, set to 0, or configured above 120 seconds lets a warehouse keep burning credits after its last query finishes. At 4 credits per hour on a Medium, a 600-second timeout pays for 10 minutes of nothing after every burst of activity, and a null setting pays until someone notices.

Signal and threshold

How ZopNight evaluates Warehouses with AUTO_SUSPEND disabled or set above 120 seconds.
Field Value
Rule IDssnowflake_wh_autosuspend_loose
Categoryorphan
Severityhigh
Metricnone — pure configuration read
Sourcesignals/hygiene/snowflake-wh-autosuspend.yaml

Idle seconds bill at the full credit rate

A Snowflake warehouse bills the same credit rate whether it is crunching a join or sitting resumed with an empty queue: 1 credit per hour for an X-Small, doubling with each size step to 128 for a 4X-Large. AUTO_SUSPEND is the only mechanism that ends the meter between bursts of work. Disable it and credits leak indefinitely after the last query; set it to 10 minutes and every working session ends with 10 paid minutes of silence.

Three ways to fail this check

The rule is an any-of over the warehouse’s auto_suspend attribute: an empty value (suspension disabled entirely), a literal 0 (same effect), or any number greater than 120 seconds. Confidence is 0.9, because this is a configuration read rather than a statistical inference, so there is very little to be wrong about. No usage metrics are consulted, deliberately: a loose AUTO_SUSPEND on a rarely-used warehouse is precisely when the setting does the most damage.

List your offenders in one pass

Terminal window
SHOW WAREHOUSES;
SELECT "name", "size", "auto_suspend"
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
WHERE "auto_suspend" IS NULL
OR "auto_suspend" = 0
OR "auto_suspend" > 120;

SHOW commands read live metadata, so unlike ACCOUNT_USAGE-based checks there is no lag. What this returns is what is configured right now.

The counterargument, and why 120 still wins

Aggressive suspension has real costs: every resume bills a 60-second minimum even for a 2-second query, and suspension drops the warehouse’s local disk cache, so the next queries re-read remote storage. That is why the threshold is 120 seconds rather than something tighter. Two minutes leaves room above the billing minimum and keeps caches warm across the short gaps inside a working session, while still ending the meter within two minutes of real inactivity. Warehouses serving latency-critical dashboards can justify more; they should be the argued exception, not the default.

Fixing it

Terminal window
ALTER WAREHOUSE analytics_wh SET AUTO_SUSPEND = 60;

Pick 60 for batch and ELT warehouses, up to 120 where interactive users notice resume latency, and pair the change with AUTO_RESUME so suspension is invisible to workloads.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·