Most of what teams spend on Snowflake Warehouses in non-production is spent while nobody is watching. In a development, staging, or QA account these resources are billed for every hour they exist, but the people who use them work a fraction of those hours. Nights, weekends, holidays, and the long tail of “we’ll get back to that environment next sprint” all meter at full price.
ZopNight closes that gap by scheduling your Snowflake Warehouses to run on your team’s hours and stop the rest of the time, without touching your data and without a migration. It is the most direct lever in FinOps, and for teams comparing tools it is where ZopNight pulls ahead of dashboard-first platforms like CloudHealth.
Why Snowflake Warehouses cost more than they should
Cloud providers bill Snowflake Warehouses by the hour whether or not anyone is using them, and most non-production fleets default to running 24/7 out of habit rather than need. At typical on-demand rates (about $2 to $4 per credit-hour, by edition) an always-on instance quietly bills the same on a Tuesday afternoon as it does at 3 AM on a Sunday.
Here is the shape of it. Say a box runs at a typical on-demand rate of $0.17 an hour. Left on around the clock that is about $124 a month, because a month is roughly 730 hours. Confine it to a single-shift work week, about 50 hours, and you pay for 50 hours instead of 730. Your own rate and hours will differ, but the ratio is the point: in non-production, most of the meter runs while nobody is working.
The instinct is usually to reach for a smaller instance type. But rightsizing only helps a resource that is genuinely too big; it does nothing for a correctly-sized resource that simply runs when no one is around. The larger, easier win is refusing to pay for the hours nobody is working, and it carries none of the performance risk of down-sizing a box that might spike tomorrow.
Stopping and starting Snowflake Warehouses safely
ZopNight handles the suspend and resume via the Snowflake warehouse API on every Snowflake Warehouses in scope, in dependency order so nothing comes up before what it depends on. A scheduled stop preserves your data exactly as a normal power-off would; ZopNight never terminates or deletes the resource, and idle detection watches CPU, network, and disk signals to surface the Snowflake Warehouses that are running but doing nothing.
In practice the setup is: Connect Snowflake as a standalone account with a key-pair JWT or PAT credential; ZopNight derives the underlying cloud from the account host; ZopNight discovers warehouses and other objects from SNOWFLAKE.ACCOUNT_USAGE and SHOW queries; Define a schedule to SUSPEND a warehouse outside working hours and RESUME it before the team needs it; Warehouses are schedulable like any VM, using the same schedules, groups, and overrides. Related reading: scheduling and cost optimization.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
Does suspending a warehouse affect my data?
No. Suspending a virtual warehouse stops its compute only. Databases, tables, and query history are untouched, and a resumed warehouse picks up exactly where it left off.
How does ZopNight connect to Snowflake?
As a standalone connection authenticated by key-pair JWT or a personal access token. ZopNight reads usage from SNOWFLAKE.ACCOUNT_USAGE and issues SUSPEND and RESUME through the warehouse API.
Which Snowflake objects does ZopNight see?
Nine object types including account, warehouse, database, user, resource monitor, table, materialized view, stage, and pipe. Warehouses are the schedulable compute object.
Can ZopNight recommend warehouse changes?
Yes. ZopNight ships Snowflake recommendations that flag idle warehouses, over and under-sized warehouses, multi-cluster limits, auto-suspend and resource-monitor guardrails, and storage cleanup on tables and stages.