Warehouses averaging under 4 credit-burning hours a day across 30 days
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | snowflake_wh_consolidate_low_active |
| Category | rightsizing |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | signals/rightsize/snowflake-wh-consolidate.yaml |
Where it applies
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
SELECT warehouse_name, DATE_TRUNC('day', start_time) AS day_bucket, COUNT(DISTINCT DATE_TRUNC('hour', start_time)) AS active_hoursFROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORYWHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP()) AND credits_used > 0GROUP BY 1, 2ORDER 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.