Scheduling warehouses · ZopDev University

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.


Tier	Engineer
JTBD	”Stop a warehouse being resumable at 3 AM by a stray query nobody meant to run.”
Personas	Platform Engineer · Data Engineer
Prerequisites	M2.12.L2 · T1.M1.3 (build your first schedule)
Time	9 minutes
Bloom verb	Put (Apply), Explain (Understand), Identify (Remember)

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

Executed by the executor's registered `snowflake-warehouse`
provider, over the connection's own credential. Nothing
Snowflake-specific reaches the schedule model: a warehouse
attaches 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, and the second one is the
only one that stops a query from resuming the warehouse.

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.

A suspended-by-schedule warehouse refuses the resume. 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; the catalog's auto-suspend guardrail signal
  flags warehouses where it is long or disabled.
  This is your baseline and it always applies.

LAYER 2: a ZopNight schedule
  Use it where a window should be genuinely closed.
  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
  refused resume 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 objects
runs through retention, transient-table choices, clustering
and search-optimization settings, which are recommendation
levers 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

Unlike a Databricks cluster stop, which terminates the cluster, a Snowflake SUSPEND is a pause. Resume restores the same warehouse with its configuration intact. There is no rebuild, no lost state, and no cold-start penalty beyond the warehouse spin-up.

That is why warehouse scheduling is a comfortable first Snowflake action: the worst realistic outcome of getting the window wrong is a failed query, not a destroyed resource.

2. Demo

A team closing a weekend window they did not know was open:

THE FINDING
  Reports -> Costs, 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)

     The Looker schedule and the dbt cron now fail on
     Saturday. Both were disabled within a week, because
     somebody finally got an error.

  RESULT
    $1,840 -> $1,310/mo. About $315 of the $410 weekend
    burn gone, and the residual 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 above 300s, or disabled, is a 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 BROKE rather than what
   saved:  ______________________________________
   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). The full catalogue is at zop.dev/learn/mcp-tools.

4. Knowledge check

Q1

A warehouse already has auto-suspend set to 60 seconds. Adding a ZopNight schedule to it:

A. Is redundant, since auto-suspend already stops it when idle
B. Overrides the auto-suspend setting
C. Answers a different question
D. Only helps if auto-suspend is disabled

Show answer

Correct: C. Auto-suspend stops the warehouse after idle time but any query resumes it; a schedule closes the window so the resume is refused. That is what stops a stray report, a retrying DAG or a BI poller from burning credits at 3 AM. The two layers compose rather than compete: keep auto-suspend tight as the always-on baseline, and use a schedule where a window should genuinely be closed. The schedule’s side benefit is that it converts silent spend into a visible error.

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, which is destructive. 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 failed query, 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 fails, not to what saves: the jobs that break are the ones auto-suspend has been quietly paying for.

Glossary terms touched

Auto-suspend · SUSPEND / RESUME · Schedulable · Virtual warehouse

Outcome

1. Concept

The obvious objection, and the answer

How the two layers compose

What is not schedulable

The stop is genuinely reversible

2. Demo

3. Hands-on (6 min)

4. Knowledge check

Q1

Q2

Q3

5. Apply

Related lessons

Glossary terms touched

Start with the bill.