Hello, We are using the open-source version of Airbyte deployed on a Linux server in GCP. On 23 June 2026, Airbyte suddenly went down. We upgraded Airbyte to the latest available version, but the sync jobs were still not working after the upgrade. As a next step, we performed a fresh installation of Airbyte, after which the sync jobs started working successfully. Has anyone experienced a similar issue or faced the same behavior with Airbyte? Any insights on the possible root cause or recommendations would be appreciated.

Similar Experiences with Airbyte Syncs Failing After Upgrade Yes, others have experienced similar issues. Based on the knowledge sources, there are a few known root causes that could explain syncs failing after an upgrade (and working after a fresh install): 1. Dataplane Group Mismatch (Most Likely Cause) A well-documented issue affects upgrades to Airbyte 2.0.x where the bootloader creates a new

dataplane_group

with a fresh UUID, while existing workloads continue to be routed to the old

AUTO

group. The workload-launcher registers under the new group and never picks up the pending workloads, causing all syncs to be stuck in "Queued" with the error: > "The workload was never claimed." This explains why a fresh install would work — it starts with a clean database state. [Dataplane Group Issue] Workaround (requires DB backup first):

-- Move all dataplanes to the AUTO group
UPDATE dataplane
SET dataplane_group_id = (
  SELECT id FROM dataplane_group WHERE name = 'AUTO' LIMIT 1
)
WHERE dataplane_group_id != (
  SELECT id FROM dataplane_group WHERE name = 'AUTO' LIMIT 1
);

Then restart the workload-launcher:

kubectl rollout restart deployment/airbyte-abctl-workload-launcher -n airbyte-abctl

2. Workspace Configuration Not Found After Upgrade Another reported issue involves the server throwing: >

IdNotFoundKnownException: Could not find configuration for STANDARD_WORKSPACE

This typically happens when upgrading across large version gaps (e.g., Helm Chart V1 to V2), where database migrations may not run correctly. [Syncs After Upgrade] 3. Silent Migration Failure There is also a known case where migrating from an older

abctl

version to a newer one results in a silent failure — the server starts successfully but silently swallows requests without dispatching workloads, with no error logs. This was traced to incomplete database migrations. [Silent Migration Failure] Recommendations • Always back up your database before upgrading. • Check bootloader logs after an upgrade to confirm migrations completed successfully:kubectl logs -n namespace bootloader-pod-name • Follow incremental upgrade paths rather than jumping across major versions. • If you're on Helm Chart V2, verify the

dataplane_group

routing in your database after any upgrade. Since a fresh install resolved your issue, the dataplane group mismatch or a failed database migration are the most likely culprits. If you plan to upgrade again in the future, the steps above should help prevent recurrence. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.