A Snowflake notebook burned €70 overnight. €0.11 of it paid for work.

Open the meter on a Wednesday morning. Nothing had been scheduled. No teammate had signed in. No job had run. The account had been quiet since lunch the day before, and so was every dashboard a person would normally check.

And yet — between noon on the 19th and 14:00 the next day, COMPUTE_WH burned 35.015 credits. At €2 a credit: €70.03. The same warehouse, left running at the same rate, was on track for €1,939 a month. The only thing it was paying for was the act of being awake.

Of all the credits COMPUTE_WH spent in thirty days, 79.83 % were spent inside this one 26-hour window.

The shape on the meter is unmistakable. Across the rest of the thirty-day pull — every other captured hour, every benchmark, every demo, every diagnostic query that produced this analysis — the warehouse spent 8.85 credits in total. The bleed window alone is four times that. Read the chart below as a tide chart: a normal account does its work in spikes; this account has a single waist-high wall of credits with everything else rounding to the floor.

The first place to look isn't the bill — it's QUERY_ATTRIBUTION_HISTORY. The table answers the question the meter doesn't: of every credit a warehouse spent, which query was responsible? Run it over the burn window and the answer is almost comically lopsided.

Of the €70.03 that COMPUTE_WH burned in twenty-six hours, €0.11 — eleven euro cents — went to attributable user query work. The rest was idle warehouse-seconds held open by a heartbeat.

The rest of the account, that same day, spent €1.64 doing real diagnostic and demo work across four other warehouses. The bleed is concentrated. One warehouse, one service holding it open, and twenty-six hours of paying to keep the lights on.

If eleven cents paid for queries, what filled the other twenty-six hours? Sort QUERY_HISTORY for the same window and the picture clears up further. Nine thousand four hundred and twelve rows. The top four patterns own 57.4 % of every query, and not one of them was typed by a human:

Read the cadence back as a clock. Once every sixty-four seconds, a sidecar health probe. Every sixty-eight seconds, a container-params ping. Every three minutes and eighteen seconds, a fresh service token. Stack the timers together and the workspace is firing a query every six or seven seconds, around the clock, all of them small, none of them yours.

That cadence is the whole mechanism. Each query takes a few milliseconds and a sliver of a credit. What they do, together, is reset COMPUTE_WH's auto-suspend countdown every minute, before it gets the chance to expire. The warehouse never goes to sleep, because something on the other end keeps tapping it awake.

All of it traces back to a single field. The notebook service that Snowsight provisions to back a workspace looked like this the whole time:

auto_suspend_secs = 0 is the field. It means the service never auto-suspends on its own. min_instances = 1 means at least one SPCS container is always running. The container fires its health probe at the bound warehouse every minute. The warehouse, in turn, resets its own auto-suspend timer on every query. The two timers loop. The loop has no exit.

COMPUTE_WH was at 600 seconds - Snowflake's default ten-minute auto-suspend. The reflex, faced with a warm warehouse, is to shorten that. It would not have helped. The sidecar health probe alone fires every ~64 seconds; stack the container-params ping and the token refresh on top and the workspace was sending a query every ~9 seconds on average. Drop the auto-suspend to 5 minutes, to 2 minutes, all the way down to the 60-second minimum Snowflake will let you set - and the very next heartbeat re-wakes the warehouse before the timer can expire. The timer never reaches the bottom, because something keeps tapping it back to the top.

A warehouse cannot auto-suspend out from under a notebook that is pinging it. The lever is upstream. The fix is at the notebook, not the warehouse.

Why it ends up at zero. Snowsight provisions notebook services as SYSTEM$MANAGED - the OWNER_ROLE on the service is NULL because Snowflake manages them on the user's behalf. The intended lifecycle is the notebook's own idle timeout, set on the notebook object itself. Close the notebook in Snowsight or hit the timeout, and the service suspends. Close the browser tab without triggering either, and with AUTO_SUSPEND_SECS = 0 as the documented default there is nothing else to stop it.

And the service itself is not anywhere most people would look. It lives in a database called USER$<your-account-name> — an auto-provisioned per-user workspace that doesn't appear in SHOW DATABASES for regular roles and isn't in Snowsight's database tree. From every normal view of the account, the service is invisible. It only surfaces from the very top:

-- run as ACCOUNTADMIN; this is the only place a workspace notebook surfaces
SHOW SERVICES IN ACCOUNT;

-- pick the row, then dig in:
DESC SERVICE USER$<account>.PUBLIC.<service_name>;
-- key columns: auto_suspend_secs, auto_resume, min_instances, query_warehouse, status

And the patch, once you've found it. The Snowflake-documented lever is the notebook's own idle timeout - IDLE_AUTO_SHUTDOWN_TIME_SECONDS, GA, 60 s floor, 24 h default. The setup docs explicitly recommend minimising it (15 min is the example they give). An optional account-wide backstop is to bind notebooks to a user-owned compute pool with its own short AUTO_SUSPEND_SECS; you cannot ALTER SYSTEM_COMPUTE_POOL_CPU directly because it is Snowflake-managed.

-- 1. Preferred: shorten the notebook's own idle timeout.
--    Workspace notebook services default to 24 h; 15 min is sensible.
ALTER NOTEBOOK <db>.<schema>.<notebook>
  SET IDLE_AUTO_SHUTDOWN_TIME_SECONDS = 900;

-- 2. Account-wide backstop (optional): your own compute pool with a
--    short AUTO_SUSPEND_SECS, then point the notebook at it. The two
--    SYSTEM_COMPUTE_POOL_* pools are Snowflake-managed and scoped to
--    specific workloads - create your own for a per-account default.
--    CPU_X64_XS is the documented smallest CPU instance family.
--    AUTO_RESUME defaults to TRUE.
CREATE COMPUTE POOL my_notebook_pool
  MIN_NODES = 1
  MAX_NODES = 1
  INSTANCE_FAMILY = CPU_X64_XS
  AUTO_SUSPEND_SECS = 900;

ALTER NOTEBOOK <db>.<schema>.<notebook>
  SET COMPUTE_POOL = my_notebook_pool;

One honest caveat: because the service is SYSTEM$MANAGED, properties set with ALTER SERVICE can be reset when the notebook is next opened in Snowsight. That is why the notebook-object lever (IDLE_AUTO_SHUTDOWN_TIME_SECONDS) is the durable one — it sits on the notebook itself, not on the managed service.

The notebook is one cause. It isn't the only one. A warehouse held warm against your intent has a small family of explanations — and the same two queries surface all of them. Run the diagnosis first. Decide which fix applies once you can see the shape of your own meter.

Two queries, runnable in a worksheet, no audit tool required. The first asks how many credits your warehouses actually burned. The second asks how many of those credits were attributed to a query a human or system ran. The gap between the two is the part of your bill that isn't paying for queries.

SELECT  warehouse_name,
        SUM(credits_used)     AS credits,
        SUM(credits_used) * 2 AS cost_eur
FROM    snowflake.account_usage.warehouse_metering_history
WHERE   start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
GROUP BY 1
ORDER BY credits DESC;

SELECT  warehouse_name,
        user_name,
        SUM(credits_attributed_compute) AS attributed_credits,
        COUNT(*)                         AS query_count
FROM    snowflake.account_usage.query_attribution_history
WHERE   start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY attributed_credits DESC;

Subtract the second result from the first, per warehouse. A small gap is normal — warehouses warm up; an idle tail before suspend is unavoidable. A large gap is a finding. On the account in this note, the gap on COMPUTE_WH was 99.84 %: of every euro spent, ninety-nine cents were not paying for a query.

Once you have a gap, the next question is what's keeping the warehouse awake. A managed notebook is the cause in this audit. In other accounts we see four other patterns just as often:

-- a) Notebook / SPCS services. Run as ACCOUNTADMIN -
--    workspace services live in USER$<name> databases hidden from SHOW DATABASES.
SHOW SERVICES IN ACCOUNT;

-- For any row, read these columns: auto_suspend_secs, min_instances, query_warehouse.
DESC SERVICE USER$<account>.PUBLIC.<service_name>;

-- b) Scheduled tasks that may be ticking too often.
SHOW TASKS IN ACCOUNT;

-- c) The query-pattern shape that gives away a heartbeat.
SELECT  client_application_id,
        user_name,
        LEFT(REGEXP_REPLACE(query_text, '\s+', ' '), 80) AS pattern,
        COUNT(*) AS cnt
FROM    snowflake.account_usage.query_history
WHERE   start_time >= DATEADD(hour, -24, CURRENT_TIMESTAMP())
GROUP BY 1, 2, 3
HAVING COUNT(*) > 100
ORDER BY cnt DESC;

A pattern that fires hundreds or thousands of times in a day, from the same client and the same user, with the same first eighty characters, is a heartbeat. The candidates name themselves.

If the culprit is a managed notebook service, this is the immediate fix. Run as ACCOUNTADMIN against the service surfaced in step 3a:

-- Documented lever. Snowflake's own notebook-setup docs recommend
-- minimising the idle timeout (15 min is sensible). 60 s floor; 24 h default.
ALTER NOTEBOOK <db>.<schema>.<notebook>
  SET IDLE_AUTO_SHUTDOWN_TIME_SECONDS = 900;

A heartbeat is not activity. A warehouse that is kept warm by something that isn't you is a bill you didn't ask for. — Field note, §5