# snowflake_wh_multicluster_min_too_high

> MIN_CLUSTER_COUNT of 2 or more multiplies a warehouse's credit rate whenever it runs (a Large goes from 8 to 16 credits per hour), yet a 14-day peak- cluster measurement below 1.5 shows the pinned extra cluster never served real concurrency. Dropping the floor to 1 restores demand-driven scale-out.

Source: https://zop.dev/integrations/snowflake/recommendations/snowflake-wh-multicluster-min-too-high
Updated: 2026-08-19

---

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

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

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