# snowflake_wh_multicluster_max_never_reached

> MAX_CLUSTER_COUNT set above 2 while the observed 14-day peak stayed below 2 concurrent clusters means the scale-out ceiling exists only on paper. ZopNight derives the peak from RESUME_CLUSTER events in WAREHOUSE_EVENTS_HISTORY; trimming the ceiling toward observed peak plus 1 caps what a misfiring workload can burst-bill.

Source: https://zop.dev/integrations/snowflake/recommendations/snowflake-wh-multicluster-max-never-reached
Updated: 2026-08-19

---

## 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

```sql
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.