# Scheduling Virtual Warehouse

> Snowflake schedules check WAREHOUSE_LOAD_HISTORY for queries in the last 5 minutes before running ALTER WAREHOUSE SUSPEND. A busy warehouse is soft-skipped, never yanked. AUTO_RESUME can still wake it on any overnight query, each resume bills a 60-second minimum, and suspension drops the warehouse cache.

Source: https://zop.dev/integrations/snowflake/warehouse/schedule
Updated: 2026-08-19

---

## A suspend that looks before it fires

The scheduled stop is not a blind ALTER statement. Before suspending, the schedule queries
WAREHOUSE_LOAD_HISTORY for activity in the trailing 5 minutes; a warehouse with recent load
is soft-skipped and retried later rather than suspended out from under a running workload.
The trade is explicit: a busy warehouse earns a later stop, never a broken query. The morning
side runs RESUME IF SUSPENDED, which is idempotent: resuming an already-running warehouse
is a no-op, so overlapping schedules and manual starts cannot conflict.

## AUTO_RESUME can overrule the calendar

Most warehouses have AUTO_RESUME enabled, meaning any query wakes them, including the ones
that arrive at 2am from a scheduled dashboard refresh, a dbt job or a metadata-polling BI
tool. A suspend schedule on such a warehouse holds only as long as nothing speaks to it.
Query history for the off-hours window names the culprits; move them, batch them onto a
dedicated small warehouse, or accept that this warehouse's nights belong to its jobs.

## The 60-second minimum punishes flapping

Every resume bills at least 60 seconds of credits regardless of how briefly the warehouse
runs. A warehouse woken 30 times a night by trickle queries pays 30 minimum charges plus its
auto-suspend tails. That pattern can cost more than staying up. Consolidating overnight
queries into one window beats letting them arrive at random far more than any single setting.

## Suspension empties the local cache

A suspended warehouse releases its compute, and with it the locally cached table data that
made repeated queries fast. First-morning queries read from remote storage and run slower
until the cache refills. For dashboards that open at 8:00, resume the warehouse at 7:45 and
let a warm-up query take the cold read.

## Credits are the unit of victory

Snowflake bills per-second credit consumption while running, so the saving is exactly the
credit-hours the warehouse no longer burns while idle. That is measurable week over week in
WAREHOUSE_METERING_HISTORY, which makes this one of the easiest schedules to prove out.