Outcome
By the end of this lesson, you will be able to put a Snowflake warehouse on a ZopNight schedule, explain how that composes with Snowflake’s own auto-suspend, and identify which Snowflake objects are not schedulable and why.
| Prerequisites | M2.12.L2 · T1.M1.3 (build your first schedule) |
| Time | 9 minutes |
1. Concept
Warehouses are Schedulable, and they run on the same scheduler-agnostic schedule model as everything else. The same schedules, the same groups, the same overrides, the same weekly grid.
WHAT ZOPNIGHT DOES Start -> RESUME the warehouse Stop -> SUSPEND the warehouse, unless it carried running load in the last 5 minutes, in which case that stop is skipped rather than landing mid-burst
Executed by the executor's registered `snowflake-warehouse`provider, over the connection's own credential. NothingSnowflake-specific reaches the schedule model: a warehouseattaches to a schedule exactly like an EC2 instance does.The obvious objection, and the answer
If an idle warehouse auto-suspends and costs nothing, why schedule it at all?
AUTO-SUSPEND answers: "stop after N minutes of no queries"A SCHEDULE answers: "do not run AT ALL during this window"
They are different questions. But a ZopNight schedule onlyissues the SUSPEND. It does not change AUTO_RESUME, so aquery that arrives in the closed window still wakes thewarehouse.Auto-suspend is reactive and unconditional: any query resumes the warehouse and starts the credit clock again. Four ordinary things will keep a warehouse alive at 3 AM on a Sunday: a scheduled report nobody reads, a retry loop in a broken pipeline, an analyst in another timezone, and a dashboard tool polling every 15 minutes. Auto-suspend faithfully suspends it again between each one, which is exactly why the bill still arrives.
To genuinely close the window, pair the schedule with AUTO_RESUME = FALSE on that warehouse, a setting you change in Snowflake yourself (ZopNight does not touch it; its scheduled Start resumes the warehouse explicitly). Then a query in the closed window fails instead of resuming. That converts “cost we did not intend” into “a query that failed and told somebody”, which is almost always the outcome you want in a non-production account.
How the two layers compose
LAYER 1: auto-suspend (Snowflake's own) Set it tight. 60 seconds is defensible on interactive warehouses; rule RC-2100 flags warehouses where it is unset, 0 or above 120 seconds. This is your baseline and it always applies.
LAYER 2: a ZopNight schedule Use it where a window should be genuinely closed, with AUTO_RESUME turned off on that warehouse. Non-prod, dev, analyst sandboxes, ETL warehouses whose jobs all run inside a known window.
DO NOT SCHEDULE A warehouse serving customer-facing queries, or any warehouse whose consumers you cannot enumerate. A closed window is an error to somebody.What is not schedulable
SCHEDULABLE warehouse RESUME / SUSPEND
NOT SCHEDULABLE account, database, user, resource-monitor, table, materialized-view, stage, pipe
None of them has a power state. A table is not "running",so there is nothing to stop. Cost control on those objectsruns through retention, transient-table choices, clusteringand search-optimization settings, which are recommendationlevers rather than schedule targets (L4).This is a narrower schedulable surface than Databricks, where clusters, pools and SQL warehouses are all schedulable. On Snowflake there is exactly one schedulable type.
The stop is genuinely reversible
A Databricks cluster stop terminates the cluster’s VMs: the configuration is kept, but in-memory state and local disk are lost and a restart takes minutes. A Snowflake SUSPEND is a pause. Resume restores the same warehouse with its configuration intact, usually within seconds. Only the warehouse’s local data cache is dropped, so the first queries after a resume can run slower.
That is why warehouse scheduling is a comfortable first Snowflake action: the worst realistic outcome of getting the window wrong is a warehouse that resumes on the next query (or, with AUTO_RESUME off, a failed query), not a destroyed resource.
2. Demo
A team closing a weekend window they did not know was open:
THE FINDING Costs → Reports, filtered to type=warehouse, weekend only.
WH_ANALYTICS_DEV $1,840/mo, of which $410 on weekends auto_suspend: 600 seconds (10 minutes) Consumers: an analyst team, all in one timezone
Weekend credit burn came from 4 sources: a Looker schedule nobody had disabled ~$180/mo an Airflow DAG retrying a failed task ~$140/mo two analysts working occasional Saturdays ~$60/mo dbt docs generation on a cron ~$30/mo
Auto-suspend was working perfectly the whole time. It suspended after each burst. The bursts were the problem.
THE FIX, IN TWO LAYERS 1. auto_suspend 600 -> 60 seconds Recovered ~$95/mo on its own, purely from the tail of each burst.
2. ZopNight schedule on WH_ANALYTICS_DEV start 0 7 * * 1-5 stop 0 20 * * 1-5 stop 0 0 * * 0,6 (weekend belt-and-braces)
3. AUTO_RESUME set to FALSE on WH_ANALYTICS_DEV, in Snowflake, so the closed window stays closed.
The Looker schedule and the dbt cron now fail on Saturday. Both were disabled within a week, because somebody finally got an error. The Airflow retry loop was fixed the same week.
RESULT $1,840 -> $1,395/mo: $95 from the auto-suspend tail plus $350 of the $410 weekend burn. The residual $60 is the two analysts, who now request an override when they work a Saturday.
THE PART THAT MATTERED MOST The schedule did not just save money. It surfaced two jobs nobody knew were running. Auto-suspend had been quietly absorbing them for a year.3. Hands-on (6 min)
1. List your warehouses and record auto_suspend for each: warehouse ______________ auto_suspend ______ s warehouse ______________ auto_suspend ______ s Anything unset, 0 or above 120s is an RC-2100 finding.
2. Filter cost to weekends only. Which warehouses burn credits on a Saturday? ______________________________________________
3. For the biggest weekend burner, enumerate its consumers. Can you name all of them? Y / N If N, do NOT schedule it yet. Find out first.
4. Build a schedule for one non-prod warehouse: start cron ____________ stop cron ____________ weekend stop ____________ Attach it and check the weekly grid for gaps.
5. One week later, record what resumed the warehouse inside the closed window: ____________________ That list is the real output of this exercise.Do it through MCP. The same task you just did in the console, asked in one sentence.
BEFORE A ZopNight account with one cloud connected. Snowflake connected, with at least one warehouse that is not serving production.ASK "List our Snowflake warehouses with their cost, and schedule the non-production ones."CHECK credit consumption after a week. Snowflake bills by credit, not by hour, which is why L2 exists.Tools behind it: list_resources (read, Explore), get_cost_by_resources (read, Cost), create_schedule (write, tier 2, reversible), attach_resource_to_schedule (write, tier 2, reversible). Connection details are in the MCP integration docs.
4. Knowledge check
Q1
A warehouse has auto-suspend at 60 seconds and AUTO_RESUME on. A ZopNight schedule suspends it at 20:00, and a stray report queries it at 03:00. What happens?
A. The query fails, because the schedule refuses the resume
B. Snowflake auto-resumes the warehouse and runs the query
C. ZopNight holds the query until the next scheduled start
D. ZopNight suspends the warehouse again as the query starts
Show answer
Correct: B. ZopNight’s Stop issues a SUSPEND and does not change AUTO_RESUME, so any query wakes the warehouse. To genuinely close the window, set AUTO_RESUME = FALSE on that warehouse in Snowflake yourself; ZopNight’s scheduled Start still resumes it explicitly. With that in place, a stray report or BI poller fails visibly instead of burning credits at 3 AM.
Q2
Which Snowflake resource types can be attached to a schedule?
A. Warehouses only
B. Warehouses, databases and pipes
C. Warehouses and resource monitors
D. Every discovered type
Show answer
Correct: A. Nothing else has a power state: a table is not “running”, so there is nothing to stop. Cost control on the other eight types runs through retention, transient tables, clustering and search-optimization settings. This is a narrower schedulable surface than Databricks, where clusters, pools and SQL warehouses are all schedulable. Snowflake has exactly one schedulable type.
Q3
How does a Snowflake warehouse Stop compare with a Databricks cluster Stop?
A. Both of them terminate the resource entirely and require a full rebuild afterwards on each occasion
B. Both are reversible pauses
C. Snowflake SUSPEND is a reversible pause: Resume restores the same warehouse with its configuration intact
D. Snowflake cannot be stopped, only resized
Show answer
Correct: C. A Databricks cluster Stop terminates the cluster’s VMs: its configuration is kept, but in-memory state and local disk are lost. This is why warehouse scheduling is a comfortable first action on a new Snowflake connection: the worst realistic outcome of a badly-chosen window is a warehouse that resumes on the next query, or a failed query if AUTO_RESUME is off, not a destroyed resource.
5. Apply
Attach a schedule to one non-production warehouse from Schedules, and tighten auto-suspend on everything at the same time. Then watch for a week and pay attention to what resumes the warehouse inside the closed window: those jobs are the ones auto-suspend has been quietly paying for.
Related lessons
- L2: The credit-based cost model
- L4: The Snowflake rule set (next)
- T2.M2.7.L2: Scheduling Databricks clusters
- T1.M1.5.L1: When you need an override
Glossary terms touched
Schedulable resource · Virtual warehouse