Skip to main content
rightsizing · snowflake

Warehouses averaging under 4 credit-burning hours a day across 30 days

resource types
1
rule IDs covered
1
severity
medium

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

How ZopNight evaluates Warehouses averaging under 4 credit-burning hours a day across 30 days.
Field Value
Rule IDssnowflake_wh_consolidate_low_active
Categoryrightsizing
Severitymedium
Metricnone — pure configuration read
Sourcesignals/rightsize/snowflake-wh-consolidate.yaml

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

Terminal window
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.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·