The most relevant info in the provided sources about “jobs not running after upgrade” is around the dataplane / scheduler behavior in Airbyte 2.x. After fixing the dataplane mapping so manual checks/syncs work, but scheduled jobs (cron / “every X hours”) still don’t run, the closest documented behavior is: - After upgrading to 2.0, some users saw that no new job pods were launched, even though connections existed and UI looked fine. [[airbyte services stuck](https://github.com/airbytehq/airbyte/issues/68115)] - Root cause there was again dataplane wiring: 2 entries in

public.dataplane_group

(old vs new), and jobs being pushed to one dataplane while the workload launcher listened to another. Aligning the

workspace.dataplane_group_id

to the active dataplane group fixed jobs starting at all. [[airbyte services stuck](https://github.com/airbytehq/airbyte/issues/68115)] You’ve already corrected a dataplane issue so that manual checks now work, which means: - Temporal, workers and workload‑launcher are at least partially healthy. - The remaining issue is specifically with scheduling. From the docs, Airbyte’s scheduler guarantees: - Syncs will run either on a fixed interval (“Scheduled” every N hours) or via CRON (Quartz‑style cron, with a timezone). [[Sync schedules](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-schedules)] - Only one sync per connection at a time; if one is running, the next scheduled one waits. - Schedule accuracy is +/- 30 minutes. [[Sync schedules](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-schedules)] However, none of the provided issues or docs explicitly describe a 2.0.1‑specific bug where cron/schedules stop running while manual checks still work. The known dataplane problems affected all jobs (manual and scheduled) until fixed. [[airbyte services stuck](https://github.com/airbytehq/airbyte/issues/68115); [No jobs starting after upgrading to version 2](https://github.com/airbytehq/airbyte/issues/68196)] Given the limits of the sources, I can’t point to a documented “cron scheduler broken in 2.0.1” issue. Within what is documented, things you can verify: 1. Dataplane consistency for all workspaces Make sure the workaround you applied is consistent across all rows:

sql    SELECT * FROM public.dataplane_group;    SELECT id, organization_id, dataplane_group_id FROM public.workspace;

All workspaces that should be running scheduled jobs need to point to the same, active dataplane group used by the workload launcher. The cited workaround only mentions updating

workspace.dataplane_group_id

and doesn’t distinguish between manual vs scheduled jobs. [[airbyte services stuck](https://github.com/airbytehq/airbyte/issues/68115)] 2. Schedule type and timing From the UI/API, confirm that the connections are still set to

Scheduled

or

Cron

and not

Manual

, and that the cron expression/timezone or interval are correct. [[Sync schedules](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-schedules)] 3. No overlapping “stuck” runs Since only one sync per connection can run at a time and scheduled runs that collide will wait until the previous finishes, confirm there are no long‑running / stuck jobs blocking subsequent schedules. [[Sync schedules](https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-schedules)] Because the sources don’t give more detail on this exact situation, I can’t reliably suggest a deeper internal fix specific to 2.0.1. If: - Dataplane group wiring is now correct for all workspaces, and - Connections are configured as Scheduled/Cron with valid expressions, and - No old jobs are stuck “Running”, then the behavior you’re seeing isn’t covered in the provided docs/issues, and you’d likely need to share Temporal / cron / workload‑launcher logs upstream (e.g., under the existing 2.x scheduler/dataplane issues) for further investigation.