Multi-cluster warehouses whose scale-out ceiling was never approached in 14 days

A ceiling that has never been touched

MAX_CLUSTER_COUNT costs nothing while unused: clusters bill only when they resume. So why flag a high ceiling? Because the ceiling defines the blast radius of a bad day. A Medium warehouse capped at 8 clusters is authorized to burn 32 credits per hour (4 per cluster) the moment a dashboard misconfiguration or a load test floods its queue. When 14 days of history show the warehouse never even ran 2 clusters at once, that authorization protects nothing and merely waits to be exercised by mistake.

Measuring peak concurrency from resume events

The metric comes from WAREHOUSE_EVENTS_HISTORY: each RESUME_CLUSTER event carries the number of the cluster that started, so the daily maximum of cluster_number is the day’s peak concurrent-cluster count. The rule takes the maximum of those daily peaks across 14 days and fires when it stays below 2 while the configured max_cluster_count attribute exceeds 2: a genuine multi-cluster ceiling that the workload has effectively never used.

Replay the measurement

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

Compare each peak against the warehouse’s configured maximum from SHOW WAREHOUSES.

Lowering a limit you never hit changes nothing, until it does

Trimming the ceiling to observed peak plus 1 leaves every normal day untouched: the auto-scaler still adds clusters when queueing appears, up to the new cap. What changes is the worst case. With the cap at 3 instead of 8, the same runaway workload maxes out at 12 credits per hour instead of 32: queueing, visibly and cheaply, instead of scaling silently and expensively. Queues page someone; credit burn often does not.

When the rule stays silent

A warehouse with no RESUME_CLUSTER events in the window produces no datapoint at all, and the rule declines to fire rather than infer a peak from absence. A suspended-all- fortnight warehouse is not evidence about concurrency. WAREHOUSE_EVENTS_HISTORY also lags up to a few hours like the other ACCOUNT_USAGE views, which a 14-day window absorbs without affecting the verdict.