Warehouses with AUTO_SUSPEND disabled or set above 120 seconds
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
| Field | Value |
|---|---|
| Rule IDs | snowflake_wh_autosuspend_loose |
| Category | orphan |
| Severity | high |
| Metric | none — pure configuration read |
| Source | signals/hygiene/snowflake-wh-autosuspend.yaml |
Where it applies
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
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
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.