Databricks jobs at least 30 days old that have not run once in the last 30 days

What a job that never runs still costs you

A job definition by itself uses no compute. The trouble is what hangs off it: a schedule that might fire unexpectedly after a data source changes, a pinned all-purpose cluster kept around because the job points at it, notebooks and libraries nobody dares delete, and noise in every list of “what runs in this workspace”. Orphaned jobs are the Databricks version of cron entries for a server that was retired years ago.

Checking a job’s recent run history

List jobs, then ask for runs that started in the last 30 days. The Jobs API takes times in epoch milliseconds, and 2,592,000 seconds is 30 days:

databricks jobs list -o json | jq -r '.[] | [.job_id, .settings.name] | @tsv'

SINCE=$(( ($(date +%s) - 2592000) * 1000 ))
databricks jobs list-runs --job-id 123456789 --start-time-from "$SINCE" -o json \
  | jq 'length'

A count of 0 means the job has not started a run in that window. databricks jobs get 123456789 shows its schedule and whether pause_status is PAUSED or UNPAUSED.

Zero runs and an old enough job

Two facts must both hold. ZopNight must have a recorded run count for the last 30 days, and it must be exactly zero. And ZopNight must know when the job was created, with that date at least 30 days in the past. A job created last week with a monthly schedule legitimately shows no runs yet, so it is spared.

Jobs that stay off the orphan list

When the run count was not collected, the rule does not guess that the job is idle. When the job’s creation time is unknown, it also stays silent, because it cannot rule out a brand-new schedule. A single recorded run inside the window clears the job. Unlike cluster rules, there is no running or stopped check: a job definition has no power state.

There is no saving figure, and why

Removing an unused job does not stop a meter on its own, so ZopNight reports this as cleanup with no dollar value. Money appears only if the job was the last reason to keep a cluster or SQL warehouse alive; that cost is picked up by the rules for those resources, such as Orphaned SQL Warehouse.

Retiring the job

1. Ask the job owner, or check creator_user_name, whether the schedule still has a purpose.
2. If it may be needed again, pause the schedule instead of deleting: set pause_status to PAUSED in the job settings.
3. Otherwise delete it with databricks jobs delete 123456789.
4. Clean up whatever it kept pinned: an all-purpose cluster it targeted, notebooks, libraries.