Job

A job is scheduled or triggered work. It has no standing cost: job clusters spin up for the run, bill during it, and tear down after. Its cost story is therefore a rate story (job compute carries a lower DBU rate than all-purpose compute) and a cadence story, because whatever a job wastes, its schedule repeats.

The quiet overspend: jobs on all-purpose clusters

A job task can bind to an existing interactive cluster instead of a job cluster. Everything works, and every run bills the higher all-purpose DBU rate, while also keeping that cluster alive to serve it. Discovery joins each job’s target cluster against the set of interactive clusters and stamps the job’s compute type as all-purpose or job-cluster, so the pattern is visible in inventory instead of buried in task JSON. Moving such a job onto a job cluster is usually a configuration-only change with an immediate rate cut.

Run history, with honesty guards

Each job carries a 30-day run count and the days since its most recent run. A genuine 0 is an orphan signal: a schedule that fires and pays for nothing anyone reads. Two guards keep the signal honest: when the runs-list probe fails the count is omitted rather than reported as zero, and job age is tracked so a recently created monthly cron is not condemned before its first scheduled fire.

Never scheduled, deliberately

ZopNight does not start or stop jobs. They exist in inventory for topology and attribution, linking recurring spend to the pipeline causing it, and their ephemeral job clusters are excluded from cluster scheduling for the same reason: the job orchestrator owns their lifecycle.

Find jobs riding interactive clusters

databricks jobs list --output json

Inspect each job’s task settings for an existing_cluster_id. Any task pointing at an interactive cluster is paying the all-purpose rate on every run; jobs defining new_cluster or referencing job_clusters are already on the cheaper meter.