Warehouses pinning a second cluster their concurrency never demanded

The floor multiplies the meter

Multi-cluster warehouses bill per running cluster: a Large at 8 credits per hour becomes 16 with two clusters up, 24 with three. MAX_CLUSTER_COUNT is harmless capacity: extra clusters resume only when queries queue. MIN_CLUSTER_COUNT is the opposite: every cluster in the floor runs whenever the warehouse runs, demand or not. Pinning the minimum at 2 doubles the cost of every active hour, bought as insurance against queueing that, for the warehouses this rule flags, never actually materialized.

What a peak below 1.5 establishes

The rule applies to warehouses whose min_cluster_count attribute is not 1, then checks the measured cluster series: the maximum of snowflake.warehouse.cluster_count_avg over 14 days must be under 1.5 to fire. The series records, per day, the highest cluster number that started, so a window maximum below 1.5 means cluster 2 was never observed starting in two full weeks. The paid-for second cluster did no distinguishable work.

Check which clusters actually started

SELECT warehouse_name,
       DATE_TRUNC('day', timestamp) AS day_bucket,
       MAX(cluster_number) AS highest_cluster_started
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_EVENTS_HISTORY
WHERE timestamp >= DATEADD('day', -14, CURRENT_TIMESTAMP())
  AND event_name = 'RESUME_CLUSTER'
GROUP BY 1, 2
ORDER BY 1, 2;

A flat column of 1s for a warehouse configured with a minimum of 2 is this finding in raw form.

Let queueing make the decision

ALTER WAREHOUSE bi_wh SET MIN_CLUSTER_COUNT = 1;

Nothing about capacity changes. The maximum stays where it was, and the auto-scaler adds cluster 2 within seconds of real queueing. What changes is who decides: with the floor at 1, concurrency demand triggers the second meter; with the floor at 2, a config line from months ago does. Warehouses with hard latency SLAs during known concurrency peaks are the legitimate exception, and they should be able to show cluster 2 starting in the event history.

Data the verdict depends on

No RESUME_CLUSTER events in the window means no datapoint and no finding. The rule does not treat a quiet fortnight as proof. The events view lags a few hours, which the 14-day horizon renders irrelevant. One boundary case worth knowing: a floor of 2 with a measured peak of exactly 2 does not fire either, since the window maximum sits above the 1.5 threshold. The rule only ever flags floors the workload demonstrably never used, never floors that were merely questionable.