cancel
Showing results forย 
Search instead forย 
Did you mean:ย 
Databricks Free Edition Help
Engage in discussions about the Databricks Free Edition within the Databricks Community. Share insights, tips, and best practices for getting started, troubleshooting issues, and maximizing the value of your trial experience to explore Databricks' capabilities effectively.
cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Jobs suddenly stopped running with no errors

Aminsn
New Contributor III

I have had a few jobs scheduled to run daily since last year. There were no problems for the first 10 months, but on 31 August 2026, the jobs suddenly stopped running, with no errors or messages indicating the cause.

I rescheduled the jobs, and they started working again. However, on 20 September, they stopped running once more, again with no warnings, messages, or errors.

I am wondering what is happening. This is very unreliable, and the fact that it occurs without any information whatsoever about the cause makes the situation unacceptable.

Can someone shed some light on this issue?

1 REPLY 1

ThomazNeto
Databricks Partner

Hi Aminsn,

I understand the frustration, but "stopped with no errors" is a useful clue. When a job fails, you see red runs. When nothing appears at all, the scheduler didn't try, which usually means the trigger was paused or the run was skipped before it started. Neither raises an error. The docs don't describe any case where Databricks pauses a schedule on its own, so something touched the job.

Three things to check, all in the job's own history:

1. Who edited the job on Aug 31 and Sep 20. Every pause/resume is a job update in the audit log. If someone deployed with a bundle in development mode, that alone pauses schedules: the docs say it "Pauses all schedules and triggers on deployed resources such as jobs". Terraform or a CI job re-deploying with pause_status: PAUSED does the same.

 
sql
SELECT event_time, user_identity.email, action_name,
       request_params.job_id
FROM system.access.audit
WHERE service_name = 'jobs'
  AND action_name IN ('update', 'reset', 'delete')
  AND event_date BETWEEN '2026-08-29' AND '2026-09-22'
ORDER BY event_time;

The system.lakeflow.jobs table also keeps every version of the job, including a paused column, so you can see exactly when it flipped.

2. Whether the runs were skipped. Open the job's Runs tab and look for pink entries. Skipped is a real status, and the docs' example is "you exceeded the maximum concurrent runs for your job or your workspace". A run that hung since Aug 31 with max concurrent runs = 1 would silently block every daily run after it. This query lists runs that never started and why:

 
sql
SELECT period_start_time, result_state, termination_code
FROM system.lakeflow.job_run_timeline
WHERE job_id = '<job_id>'
  AND period_start_time = period_end_time
ORDER BY period_start_time DESC;

3. The Run as user. If that user was deactivated or left, the docs say jobs "fail unless they are assigned to a new owner". That would show as failures, not silence, but worth ruling out. Set Run as to a service principal either way.
https://docs.databricks.com/aws/en/jobs/privileges

Docs:
https://docs.databricks.com/aws/en/jobs/triggers
https://docs.databricks.com/aws/en/jobs/monitor
https://docs.databricks.com/aws/en/admin/system-tables/jobs
https://docs.databricks.com/aws/en/dev-tools/bundles/deployment-modes

If you post the result of the first query, we can probably name the cause.

Thomaz A. Rossito Neto
Principal Data Architect & AI Strategy โ€” CI&T
thomazn@ciandt.com
linkedin.com/in/thomaz-antonio-rossito-neto