A Snowflake warehouse burns credits around the clock though analysts query it only at 9am — why?

## Frame the problem correctly Snowflake bills a virtual warehouse for **every second it is in the running state**, regardless of whether a query is executing, with a 60-second minimum per start. So "burning credits all day" is never mysterious: the warehouse is up all day. The diagnostic question is *what keeps it up*, and there are only a few possibilities. ## 1. Auto-suspend is disabled `AUTO_SUSPEND = NULL` or `0` means the warehouse runs until a human suspends it. This is the single most common cause and it usually has the same history: someone disabled it while debugging cache-warmth complaints, or created the warehouse from a script that omitted the property. Check it directly: ```sql SHOW WAREHOUSES; -- inspect auto_suspend / auto_resume per warehouse ``` Audit the whole account for this, not just the warehouse that showed up on the bill. ## 2. The suspend delay is longer than the gaps between queries `AUTO_SUSPEND = 3600` on a warehouse that gets a query every 40 minutes never suspends — every arrival resets the idle timer. The setting is present, looks configured, and does nothing. Compare the delay against the actual arrival pattern in query history rather than against intuition. ## 3. A statement is still running Auto-suspend fires only when the warehouse is **idle**. A query stuck for hours — a runaway cross join, a client that opened a cursor and stopped fetching, a load waiting on something external — keeps the warehouse busy and therefore billing. Look for long-running statements in query history or `SHOW ... ` running-query surfaces, and then prevent recurrence with a statement timeout: ```sql ALTER WAREHOUSE etl_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 3600; ``` The account default for `STATEMENT_TIMEOUT_IN_SECONDS` is very high (48 hours), which is effectively no protection; setting a realistic per-warehouse value is standard hygiene. ## 4. Something is polling the warehouse Scheduled **tasks**, Stream-consuming jobs, ingestion pipelines, a BI tool's health check, or a monitoring dashboard that runs a query every minute will all keep the idle timer from ever expiring. Each individual query is trivial; the effect is a warehouse that runs 24 hours for a few minutes of real work. The fix is architectural: move high-frequency polling to a dedicated tiny warehouse whose cost you accept, batch the schedule so the warehouse gets real idle windows, or replace the polling with metadata-only checks that need no warehouse at all. ## 5. Maximized multi-cluster mode If `MIN_CLUSTER_COUNT` is greater than 1, then whenever the warehouse is running it runs *that many* clusters, each billing at the size's credit rate. The warehouse still suspends when fully idle, but a mostly-idle maximized warehouse multiplies whatever idle time remains. Check the cluster counts before concluding the size is the problem. ## What is not the cause Two beliefs come up in interviews and both are wrong: - **Idle sessions.** An open connection or a logged-in user does not keep a warehouse running. Only executing statements do. - **Cached results.** Serving a query from the results cache in the cloud services layer does not require the warehouse and does not resume it. ## Turning the diagnosis into a fix Once you know which cause it is, the remedies are ordered by permanence: 1. Restore `AUTO_SUSPEND` to a value matched to the workload's arrival pattern, and `AUTO_RESUME = TRUE` so nothing breaks for users. 2. Set `STATEMENT_TIMEOUT_IN_SECONDS` on every warehouse so no single statement can hold compute indefinitely. 3. Separate workloads: give polling, ETL and interactive users their own warehouses so one pattern's arrival rate does not hold another's compute up. 4. Attach a **resource monitor** with a credit quota and a suspend trigger, so the next occurrence has a ceiling instead of a bill. 5. Alert on the pattern, not just the total: a warehouse whose running hours per day approach 24 is the signal, and it appears long before the invoice does. ## Why interviewers like this question It is the most common real Snowflake incident, and it separates people who have operated an account from people who have read the docs. A strong answer enumerates causes, names the evidence for each, and finishes with the guardrails that stop it recurring — not just "turn auto-suspend on."