Interactive Cluster
Does ZopNight manage Interactive Cluster?
All-purpose Databricks clusters bill 2 meters simultaneously: DBUs at the all-purpose rate, which is priced above job compute, and cloud VM hours for the driver plus every worker. Auto-termination set to 0 minutes means the cluster never stops itself, so ZopNight terminates interactive clusters on schedule outside working hours.
Rules that fire on Interactive Cluster
At a glance
| Field | Value |
|---|---|
| Scheduling notes | Stop issues a cluster Terminate, which is destructive to cluster state; restart recreates compute on resume. Applies to interactive clusters only |
An interactive (all-purpose) cluster is a driver plus workers used for notebooks and ad-hoc analysis. While it runs it feeds both Databricks meters at once: DBUs at the all-purpose rate (priced above the job-compute rate for the same machines) and cloud VM hours for every node. A cluster left up overnight pays both meters to do nothing.
What counts as interactive
Discovery keeps only clusters whose cluster source is UI or API: the ones humans created. Clusters materialized by the platform for job runs, pipelines, SQL warehouses, and model serving are system by-products, excluded from inventory and scheduling alike. Captured metadata includes node type, Spark version, runtime engine, availability, policy, any backing instance pool, and the auto-termination window.
Pricing an autoscaling cluster honestly
For autoscale clusters the fixed worker count reads 0 and the truth lives in the min and max bounds. Billing at max assumes the cluster always runs flat out; billing at min assumes it never scales. ZopNight uses the midpoint of the autoscale range, clamped to at least 1 worker, plus 1 driver, multiplied by node rate and on-hours. That proxy avoids inflating either the cost or the projected savings.
Auto-termination alone is not enough
An autotermination_minutes of 0 means the cluster never stops itself. Even a sane value only measures inactivity: a dashboard or notebook that pokes the cluster hourly resets the clock forever. Schedules exist on top of auto-termination, not instead of it. The schedule enforces working hours; the timeout catches gaps inside them.
Stopping is a Terminate, and that is destructive
The scheduled stop issues a cluster Terminate, which discards running state; resume recreates the compute fresh. That trade is acceptable for interactive workloads precisely because their state is disposable, and it is why job, pipeline, SQL, and model-serving clusters are never scheduled.
See who never stops
databricks clusters list --output jsonScan the output for state, cluster_source, and autotermination_minutes. A cluster in RUNNING state with source UI and a termination window of 0 is the first candidate for a schedule.