Scheduling Instance Pool
Can ZopNight schedule Instance Pool?
Pool schedules set minimum idle instances to 0, releasing the standby VMs a pool holds warm. Those machines bill cloud VM rates around the clock while earning no DBUs. Nothing is blocked overnight: clusters using the pool still start, they just cold-provision, and the saved minimum returns at the scheduled resume.
How the stop works
| Field | Value |
|---|---|
| Behaviour | sets the pool's minimum idle instance count to 0, releasing standby VMs; the saved minimum is restored on resume |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
The idle floor is pure standby spend
An instance pool’s minimum idle count keeps that many VMs warm at all times so clusters can grab them instantly. Those idle machines bill their cloud VM rate every hour. Databricks charges no DBUs for idle pooled instances, but Azure or AWS charges for the VMs all the same. A minimum of 8 mid-size instances held warm overnight is 8 VMs’ worth of rent for latency nobody is there to enjoy. The schedule drops that floor to 0 in the evening and restores the saved value in the morning.
Nothing stops working at night
Zeroing the floor blocks nothing. A cluster that requests instances from the pool at 2am still gets them, freshly provisioned from the cloud rather than handed over warm. The trade is start latency, minutes instead of seconds, paid only by whoever actually shows up at 2am. Of all the schedules on this directory, this one is closest to free of failure modes: no evictions, no lost state, no refused work.
Warm mornings are part of the contract
The resume half restores the minimum ahead of business hours, so the pool re-fills with warm instances before the first notebook attaches. Set the resume 10-15 minutes early, since the pool needs time to provision its floor, and the day’s first cluster start is as fast as it ever was.
Max capacity is untouched
Only the minimum moves. The pool’s maximum stays where it was, so burst behavior during the night window is identical to daytime; the schedule shapes the floor, never the ceiling.
Pair it with the cluster and warehouse schedules
Pools rarely idle alone; the same workspace usually has abandoned interactive clusters and always-on warehouses. The pool schedule removes the quietest of the three wastes, the one no dashboard flags, because idle pooled VMs look intentional. Auditing the floor against actual overnight cluster starts is usually the fastest few hundred dollars in the workspace.