Subject: Job Failures – Workload Heartbeat Error / No exit code found Body: Hello Airbyte Support Team, We are experiencing multiple job failures on Managed Airbyte Cloud. Below are the details: • Environment: Managed Airbyte Cloud • Job ID: 3033 • Time: 2025-12-08 03:23 UTC • Connectors affected: dok_system_tables.* (multiple connectors) • Error messages observed: ◦

Workload Heartbeat Error

◦

No exit code found

◦

Input was fully read, but some streams did not receive a terminal stream status message

◦ Streams without terminal status:

summary_storage_delivery_date

,

summary_storage_delivery

,

product_link_all

,

landing_url

• Logs: (attached / see exported logs) • Additional notes: ◦ The failures happen on multiple connectors. ◦ Large datasets are being synced. ◦ We are unsure if Airbyte version was recently updated. ◦ The errors suggest potential instability in the workload API or pods, but as this is Managed Airbyte Cloud, we do not have access to internal pod logs or Kubernetes events. Could you please investigate why these jobs are failing and advise on a resolution? We want to ensure reliable replication for these connectors.

Based on the information in the shared sources, there are two distinct but related classes of symptoms that match what you’re seeing: 1. Workload heartbeat–related failures / “Workload Heartbeat Error” 2. Container exit handling failures / “No exit code found” Because you’re on Managed Airbyte Cloud, only the Airbyte team can inspect the underlying workload pods and platform version; you won’t have access to those internals yourself. --- ### 1. Workload heartbeat errors Airbyte uses a heartbeat / timeout mechanism to detect when source and destination workloads are no longer making progress: - For sources, any

RECORD

or

STATE

message counts as a heartbeat; if the time since the last message exceeds

heartbeat-max-seconds-between-messages

(default 3 hours), the platform marks the source as unresponsive and fails the sync with a message like

The source is unresponsive

or a generic heartbeat error. [[Heartbeats](https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details)] - For destinations, there is a timeout on long‑running calls; if a call exceeds

destination-timeout-max-seconds

(default 24 hours), the platform considers the destination unresponsive and may fail the sync. [[Heartbeats](https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details)] On self‑hosted deployments, these thresholds can be tuned in

flags.yaml

(e.g. increasing

heartbeat-max-seconds-between-messages

for long‑running, large syncs). [[Heartbeats](https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details)] Your symptoms: - Large datasets - Multiple connectors affected - Message:

Workload Heartbeat Error

and “Airbyte could not track the sync progress. Sync process exited without reporting status.” in a similar case [[All sync jobs hanging](https://github.com/airbytehq/airbyte/issues/55812)] are consistent with the platform detecting that it can no longer reliably track the workload’s progress (no heartbeats or an abnormal termination of the workload). On Managed Cloud, only the Airbyte team can: - Check whether heartbeat / timeout flags changed or are misbehaving. - Correlate this to any platform upgrade or incident around your job’s timestamp. - Inspect workload-level logs and metrics (OOM, node failures, transient infra issues, etc.) that might cause the job to die before sending final status messages. --- ### 2. “No exit code found” & missing terminal stream status The error

No exit code found

is thrown when the worker cannot retrieve a container’s exit status, typically because the process or pod has already disappeared or never completed as expected: - Seen during source read or destination write in multiple open issues: [[source-snowflake issue](https://github.com/airbytehq/airbyte/issues/56456); [bigquery issue](https://github.com/airbytehq/airbyte/issues/59702)] - In Kubernetes-based deployments, a related symptom is

Cannot find pod while trying to retrieve exit code. This probably means the Pod was not correctly created.

[[Cannot find pod](https://discuss.airbyte.io/t/2421)] In those cases, replication logs show that data transfer appears to be progressing, and sometimes even that streams are finalized, but the worker ultimately fails because it cannot get a valid exit code or a complete set of terminal statuses from all streams. [[source-snowflake issue](https://github.com/airbytehq/airbyte/issues/56456)] Your message: >

Input was fully read, but some streams did not receive a terminal stream status message

(for specific streams) matches the same pattern: the workload exited (or was lost) before it could emit terminal status messages for all streams, so: - The heartbeat / workload monitor reports a generic “Workload Heartbeat Error”. - The worker reports

No exit code found

while attempting to read the workload’s exit status. [[source-snowflake issue](https://github.com/airbytehq/airbyte/issues/56456); [bigquery issue](https://github.com/airbytehq/airbyte/issues/59702)] --- ### What this likely means for your Managed Cloud environment From the available information, the failures are not clearly attributable to your connector configs alone, especially because: - Multiple connectors and streams are affected. - Large volumes and long runtimes make heartbeat/timeout and workload stability more critical. - Similar failures (

Workload heartbeat … process exited without reporting status

,

No exit code found

, missing terminal stream status) have been observed in other environments and tied to workload/pod lifecycle or worker error‑handling issues, not to user misconfiguration. [[All sync jobs hanging](https://github.com/airbytehq/airbyte/issues/55812); [source-snowflake issue](https://github.com/airbytehq/airbyte/issues/56456)] However, the shared sources do not provide: - A definitive root cause for this exact combination of errors on Managed Cloud. - A documented, guaranteed fix that you can apply yourself on Cloud (e.g. a specific flag or version that must be changed). So the best we can say from the docs and issues is: - The pattern strongly suggests workload instability or lifecycle issues (pods exiting early, being cleaned up, or heartbeat/exit‑code handling bugs) on the platform side. - For large, multi‑stream workloads, this can manifest as input fully read but no final status for some streams, combined with

No exit code found

and heartbeat errors. --- ### Recommended next steps for resolution (Managed Cloud) Because you’re on Managed Cloud and do not control the underlying infra, the next practical step is for the Airbyte Cloud team to investigate this specific job and environment: When you open/continue your support ticket, include the following (most you’ve already provided): 1. Environment: Managed Airbyte Cloud. 2. Job ID and time: Job 3033 at 2025‑12‑08 03:23 UTC. 3. Connectors / streams: All affected dok_system_tables.* connections; explicitly list the streams missing terminal status (

summary_storage_delivery_date

,

summary_storage_delivery

,

product_link_all

,

landing_url

). 4. Observed errors (verbatim): -

Workload Heartbeat Error

-

No exit code found

-

Input was fully read, but some streams did not receive a terminal stream status message

5. Attach the exported logs for that job and mention that symptoms match known patterns where the worker cannot retrieve exit codes or final stream statuses. [[source-snowflake issue](https://github.com/airbytehq/airbyte/issues/56456); [All sync jobs hanging](https://github.com/airbytehq/airbyte/issues/55812)] 6. Ask explicitly for: - Confirmation of which platform version and workload-API / heartbeat / worker versions were running at that time. - Review of workload/pod logs and events around that timestamp (OOM, node drain, restart, internal errors). - Whether there are any known incidents or open bugs around heartbeat monitoring and exit-code handling for large multi‑stream syncs in your version. - Whether they can tune heartbeat/timeout settings for your environment, or recommend splitting certain very large / slow streams into separate connections if necessary. Given the nature of Managed Cloud, only the internal team can conclusively determine whether this is: - A transient platform incident (infra/node issue), - A known bug in the worker / workload monitor / heartbeat logic, - Or a workload size/shape pattern that needs configuration tuning on their side. The shared knowledge sources do not contain enough detail to pinpoint the exact cause of your job ID 3033, so a deeper internal investigation by the Cloud team is required.