# snowflake_wh_consolidate_low_active

> Warehouses whose count of active hours, hours that actually burned credits, averages below 4 per day over a 30-day window are consolidation candidates. Each sparse warehouse pays its own resume cycles and 60-second minimum bills; merging two of the same size onto one keeps the rate while halving that overhead.

Source: https://zop.dev/integrations/snowflake/recommendations/snowflake-wh-consolidate-low-active
Updated: 2026-08-19

---

## Four active hours is the line

A warehouse that works 3 hours a day and sleeps 21 is not a problem by itself.
Auto-suspend exists for exactly that shape. The waste appears when a team runs five such
warehouses of the same size, each waking for its own scattered jobs. Every one of those
resumes bills Snowflake's 60-second minimum, re-warms its own cache from nothing, and
rides its own auto-suspend tail. The same jobs pointed at one shared warehouse of the
same size would run at the same credit rate and split those fixed costs.

## Where the number comes from

The metric is a per-day count of distinct hours in which the warehouse consumed any
credits, derived from WAREHOUSE_METERING_HISTORY rows where `credits_used` is greater
than 0. The rule averages that daily count over a 30-day window and fires below 4. It
is a measure of how often the warehouse is on, not how hard it works while on. A
warehouse pegged at 100% load for 3 hours a day still fires, and that is intentional:
the consolidation case rests on sparseness, not on low load.

## Chart your own per-day activity

```sql
SELECT warehouse_name,
       DATE_TRUNC('day', start_time) AS day_bucket,
       COUNT(DISTINCT DATE_TRUNC('hour', start_time)) AS active_hours
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())
  AND credits_used > 0
GROUP BY 1, 2
ORDER BY 1, 2;
```

Metering data lags up to 3 hours, which is immaterial at a 30-day horizon.

## What merging actually changes

Consolidation only makes sense between warehouses of the same size and workload class: merging
a Small into a Large quadruples the rate the Small's queries pay. The wins are
shared resume cycles, one warm cache instead of several cold ones, and fewer minimum
bills. The risk is queue contention: two workloads that peak at the same hour will now
queue behind each other, so check the overlap of active hours before merging anything
with an SLA.

## Advisory by design

Confidence is 0.6 and there is no automated remediation, because no API can know which
warehouses are politically and operationally safe to merge. ZopNight surfaces the
candidates; the merge itself is a re-pointing of connections and a DROP WAREHOUSE at
your pace.