Credits by Warehouse (7d), Snowflake

​

At a glance

A bar chart of credit consumption broken out per warehouse over the last 7 days. Where Credits Burned (24h) tells you how much the account spent, this card tells you where the spend lives. That distinction is the whole point: a Snowflake account is rarely uniformly expensive; cost concentrates in one or two warehouses, and the shape of the bars is what drives every sizing and scheduling decision you will make. A tall BI_WH bar says your dashboards are the cost centre. A tall AD_HOC_WH bar says exploratory work is. A LOAD_WH bar that creeps up week on week says your ingest is scaling with the business. Reading the distribution, not just the total, is how a platform team decides what to right-size, what to schedule off-peak, and where a multi-cluster or a smaller default would pay back.

​

Calculation

per_warehouse_credits =
  SELECT name, SUM(credits_used)
  FROM WAREHOUSE_METERING_HISTORY
  WHERE start_time >= now − 7d
  GROUP BY name
  ORDER BY SUM(credits_used) DESC

bar_height_$  = credits_per_warehouse × dollar_per_credit

• Size sets the rate, runtime sets the bar. A warehouse’s credit rate doubles per size step (X-Small 1/hr through 4X-Large 128/hr). A small warehouse that runs constantly can out-burn a large one that runs briefly, so a tall bar is the product of size and uptime, not size alone.
• Idle time inflates bars. Credits accrue until AUTO_SUSPEND fires. A warehouse with a long auto-suspend and a sparse, bursty workload shows a taller bar than its query count would suggest; cross-reference Idle Warehouse Credits Wasted (24h) to split working from idling.
• Multi-cluster warehouses sum their clusters. A multi-cluster warehouse bills for every active cluster. Its bar is the total across all clusters that ran during the window, so a multi-cluster scaling out under concurrency pressure shows a step up even at the same nominal size.
• The ranking is the actionable part. The top one or two bars almost always account for the majority of spend (a Pareto distribution is typical). Right-sizing the top bar moves the account total far more than tuning the long tail.

​

Worked example

1. The top bar is where the money is. Tuning TRANSFORM_WH (4%) is irrelevant; halving BI_WH (56%) saves more than the bottom two warehouses cost combined. Open Warehouse Saturation % for BI_WH: it shows the multi-cluster scaling to 3 clusters every weekday 09:00 to 11:00 (the morning dashboard rush) and sitting at 1 cluster otherwise.
2. Is the multi-cluster earning its keep or masking inefficiency? Check Avg Query Queue Depth per Warehouse. If the queue is near zero even at peak, the third cluster is rarely needed and MAX_CLUSTER_COUNT could drop to 2. If the queue spikes, the scale-out is genuinely serving concurrency and should stay.
3. Schedule the controllable bar off-peak. AD_HOC_WH at 25% is exploratory. Much of it is data-team work that has no deadline. Encouraging heavy exploratory queries onto a scheduled window, or onto a smaller default warehouse, trims the second-biggest bar without affecting the business-facing dashboards.

Right-sizing leverage, ranked:
  BI_WH       56% → 1% saved here = $35/wk; realistic 20% trim = $700/wk
  AD_HOC_WH   25% → schedule off-peak / default smaller = ~$300/wk
  LOAD_WH     15% → ingest scales with business; leave it
  TRANSFORM   4%  → not worth touching

1. Always tune the top bar first. Credit distributions are Pareto-shaped; the top one or two warehouses dominate. Effort spent on the long tail is wasted effort.
2. A tall bar is not automatically waste. A warehouse that is large and busy because it is genuinely serving load is doing its job. Pair every tall bar with Warehouse Saturation % and queue depth before assuming the size is wrong.
3. Watch for week-on-week creep in the load bar. LOAD_WH rising steadily is usually healthy (the business is generating more data), but it is also the early signal that ingest will need its own attention before it becomes the top bar.

​

Sibling cards to reference together

​

Reconciling against the source

Per-warehouse credits, last 7 days: SELECT name, SUM(credits_used) AS credits FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY WHERE start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP()) GROUP BY name ORDER BY credits DESC; Compute vs cloud-services split per warehouse: the same view exposes credits_used_compute and credits_used_cloud_services if you need to see which warehouses are metadata-heavy. Size-change history: SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_EVENTS_HISTORY WHERE event_name = 'ALTER_WAREHOUSE' ORDER BY timestamp DESC; to date any resize that changed a bar. Managed console: Snowsight under Admin -> Cost Management -> Consumption, grouped by warehouse, is the native bar chart this card mirrors. It is the canonical view your account team uses to attribute the invoice across warehouses.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre