Credits Burned (24h), Snowflake

​

At a glance

The single most Snowflake-defining number on the dashboard: total compute credits consumed across the account in the last 24 hours, compared against the prior 24 hours. In Snowflake, credits are dollars. Every second a warehouse runs, it accrues credits at a rate set by its size, and those credits convert directly to your invoice. So this card is not an abstract usage metric; it is the daily spend meter. A flat line is a controlled account. A sudden step up, with no matching rise in work done, is money leaving the building: a runaway query, a scheduled job stuck in a retry loop, an auto-suspend setting that quietly stopped working, or a warehouse someone resized up and forgot. The +50% vsP alert exists because a doubled daily burn caught the same day is a saved bill; caught at month end it is a finance conversation.

​

Calculation

credits_24h  = sum(credits_used) from METERING_HISTORY
               where start_time >= now − 24h
credits_prior = sum(credits_used) from METERING_HISTORY
               where start_time in [now − 48h, now − 24h)
delta_vsp    = (credits_24h − credits_prior) / credits_prior
dollars_24h  = credits_24h × dollar_per_credit

• Per-second billing with a 60-second floor. A warehouse bills per second while running, but every resume carries a 60-second minimum charge. Many tiny queries that each spin a warehouse up and down can therefore burn far more credits than their runtime suggests, because each pays the floor.
• Size doubles the rate. Credit consumption per hour doubles with each warehouse size step: X-Small burns 1 credit/hour, Small 2, Medium 4, Large 8, X-Large 16, and so on. Resizing a warehouse up one step doubles its burn rate instantly, which is the single most common cause of a sudden +50% jump.
• Idle-but-running counts. A warehouse that is on but processing nothing still accrues credits until AUTO_SUSPEND kicks in. This idle burn lands in the total even though no query ran; see Idle Warehouse Credits Wasted (24h).
• Serverless credits are separate line items. Snowpipe, automatic clustering, and materialised-view maintenance run on Snowflake-managed compute and accrue credits independently of your warehouses. A clustering job kicked off by a large reorganisation can spike the total with no warehouse activity at all.
• Cloud-services credits have a free tier. Cloud-services compute (query compilation, metadata) is free up to 10% of daily warehouse credits; only the excess is billed and included here. A workload of many tiny metadata-heavy queries can push past that 10% line.

​

Worked example

1. Confirm the resize. Open Credits by Warehouse (7d) and look at BI_WH over the week; the step is obvious and dated. Cross-check WAREHOUSE_EVENTS_HISTORY for the ALTER WAREHOUSE ... SET WAREHOUSE_SIZE event and who ran it.
2. Decide if the size was justified. Was BI_WH queueing? Check Warehouse Saturation % and Avg Query Queue Depth per Warehouse. If saturation was comfortable and the queue was empty, the X-Large is pure waste: resize back to Medium and reclaim ~$865/day.
3. If the resize was deliberate but excessive, a multi-cluster Medium (scale-out for concurrency) is usually cheaper than a single X-Large (scale-up for one big query) when the problem is concurrency rather than single-query size.

Cost of leaving it unfixed:
  Extra burn:  384 − 96 = 288 credits/day
  Dollar cost: 288 × $3.00 = $864/day
  Over a 30-day month if unnoticed: ~$25,900
Caught same-day by the alert: one ALTER WAREHOUSE statement, ~$865 saved per day.

1. A doubling on one warehouse is almost always a resize. Credit burn scales linearly with size, so clean multiples (2x, 4x) point at WAREHOUSE_SIZE changes, not query behaviour. Ragged increases point at query inefficiency or volume.
2. The alert pays for itself on day one. A +50% burn left until month-end is the classic Snowflake bill-shock story. The whole point of the 24-hour window is to catch it while a single ALTER statement fixes it.
3. Storage is not in this number. A growing bill with flat credit burn means storage, not compute; read Storage Used (TB) for that axis.

​

Sibling cards to reference together

​

Reconciling against the source

Total credits, last 24h: SELECT SUM(credits_used) AS credits FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY WHERE start_time >= DATEADD('hour', -24, CURRENT_TIMESTAMP()); Per-warehouse split: SELECT name, SUM(credits_used) FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY WHERE start_time >= DATEADD('hour', -24, CURRENT_TIMESTAMP()) GROUP BY name ORDER BY 2 DESC; Serverless credits: AUTOMATIC_CLUSTERING_HISTORY, PIPE_USAGE_HISTORY, and MATERIALIZED_VIEW_REFRESH_HISTORY each carry their own credits_used. Managed console: Snowsight under Admin -> Cost Management -> Consumption shows daily credit totals with a warehouse and service breakdown. This is the closest native equivalent and is what your account team reconciles the invoice against. Multiply by your contracted rate to match the dollar figure.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre