Instance Pool
Does ZopNight manage Instance Pool?
Idle instances in a Databricks pool bill the cloud VM rate with 0 DBU charge. That is the entire point of a pool, and its entire risk, because min_idle_instances VMs sit warm around the clock whether or not any cluster attaches. ZopNight schedules pools by setting minimum idle to 0 off-hours and restoring it on resume.
Rules that fire on Instance Pool
At a glance
| Field | Value |
|---|---|
| Scheduling notes | sets the pool's minimum idle instance count to 0, releasing standby VMs; the saved minimum is restored on resume |
An instance pool keeps pre-warmed VMs on standby so clusters attach in seconds instead of minutes. Its billing is deliberately asymmetric: instances waiting in the pool bill the cloud VM rate and no DBUs at all. That asymmetry is the entire value of the object (warm capacity at machine cost) and the entire risk, because warm capacity is a standing hourly bill that demand may never justify.
Why the Databricks side reads zero
DBUs are charged when clusters consume instances, not while instances wait. A pooled VM sitting idle is cheaper than an idle cluster on the same hardware, which is exactly what tempts teams to keep generous floors “for fast starts”. The bill looks like it belongs to nobody because no workload is attached to it.
The floor is the commitment
min_idle_instances is a promise to hold that many VMs warm around the clock. Pools also report live utilization, instances currently idle versus attached to clusters, and an idle-instance auto-termination window, but that trimming only applies above the floor, never below it. The floor moves only when someone edits it, which on most teams means it never moves.
Scheduling edits the floor, terminates nothing
ZopNight prices a pool at node rate times minimum idle instances times hours, and schedules it by setting the minimum idle count to 0 during quiet hours, restoring the saved minimum on resume. No instance is torn out from under a cluster; the pool simply stops holding standby capacity through the hours nobody will claim it.
Utilization data picks the right floor
Live idle and used counts, watched across a working day, answer whether the floor is sized to demand or to habit. A floor sized for Monday-morning bursts that persists through weekends is the standard finding.
Check pool utilization now
databricks instance-pools list --output jsonCompare each pool’s min_idle_instances against its live stats: idle versus used counts. A pool showing high idle and 0 used through business hours is over-floored even before any schedule enters the picture.