@kapa.ai sync dies midway with

message='activity Heartbeat timeout', timeoutType=TIMEOUT_TYPE_HEARTBEAT

between Salesforce source and Postgres destination. What does this mean?

Activity Heartbeat Timeout Between Salesforce and Postgres This error means that Airbyte's internal heartbeat monitoring detected that your sync job stopped making progress — specifically, the source (Salesforce) did not emit any

RECORD

or

STATE

messages within the configured heartbeat threshold (default: 3 hours). [Heartbeats Docs] Why This Happens The Airbyte platform monitors messages from the source and destination as "heartbeats." If no message is received within the threshold, the sync is failed and restarted automatically. [Heartbeats Docs] For Salesforce specifically, this is a known issue: > Certain API sources take an unknown amount of time to generate asynchronous responses (e.g., Salesforce, Facebook, Amplitude). No workaround currently exists. Salesforce often generates reports or query results asynchronously, meaning the connector may be waiting silently for a response — with no records emitted — for longer than the heartbeat threshold allows. [Heartbeats Docs] What You Can Do 1. Understand it may be transient — Airbyte will automatically restart the job. If it consistently fails, it's worth investigating further. 2. Check which streams are syncing — Some Salesforce streams (especially large or report-based ones) are more prone to this. Try disabling problematic streams to isolate the issue. 3. Increase the heartbeat threshold (self-hosted only) — You can modify `flags.yaml`heartbeat max seconds between messages value in seconds # default is 10800 (3 hours) heartbeat.failSync: true # set to false to log but not fail the sync[Heartbeats Technical Details] 4. If on Airbyte Cloud — There is no workaround for async API sources like Salesforce at this time. Reach out to Airbyte Support for assistance. [Heartbeats Docs] Summary The Postgres destination is unlikely to be the root cause here — database destination errors are described as "extremely rare." The Salesforce source's async behavior is the most probable culprit. [Heartbeats Docs] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

These are the last few log lines before failure @kapa.ai The last platform

Records read

and Retry State are less than 2 minutes apart.

2026-08-03 04:00:26 destination > 2026-08-03 04:00:26 INFO i.a.c.i.d.GlobalMemoryManager(free):88 - Freeing 9981764 bytes..
2026-08-03 04:00:26 destination > 2026-08-03 04:00:26 INFO i.a.c.i.d.FlushWorkers(lambda$flush$1):167 - Flush Worker (3d41e) -- Batch contains: 1431 records, 10.48 MB bytes.
2026-08-03 04:00:28 destination > 2026-08-03 04:00:28 INFO i.a.c.i.d.GlobalMemoryManager(free):88 - Freeing 0 bytes..
2026-08-03 04:00:28 destination > 2026-08-03 04:00:28 INFO i.a.c.i.d.GlobalMemoryManager(free):88 - Freeing 10989756 bytes..
2026-08-03 04:00:28 destination > 2026-08-03 04:00:28 INFO i.a.c.i.d.FlushWorkers(lambda$flush$1):176 - Flush Worker (3d41e) -- Worker finished flushing. Current queue size: 198
2026-08-03 04:00:37 platform > Records read: 780000 (5 GB)
2026-08-03 04:01:12 platform > Retry State: RetryManager(completeFailureBackoffPolicy=BackoffPolicy(minInterval=PT10S, maxInterval=PT30M, base=3), partialFailureBackoffPolicy=null, successiveCompleteFailureLimit=5, totalCompleteFailureLimit=10, successivePartialFailureLimit=1000, totalPartialFailureLimit=10, successiveCompleteFailures=2, totalCompleteFailures=2, successivePartialFailures=0, totalPartialFailures=0)
 Backoff before next attempt: 30 seconds

Analyzing Your Log Lines Looking at your logs, the pattern tells a clearer story than a typical Salesforce async timeout: What the Logs Show The gap between the last

Records read

and the failure is ~35 seconds — far shorter than the 3-hour heartbeat threshold. This means the heartbeat timeout is not what killed this specific attempt. What Actually Happened The

Retry State

log reveals the real picture:

successiveCompleteFailures=2, totalCompleteFailures=2
successivePartialFailures=0, totalPartialFailures=0

This was a complete failure (no data synced in this attempt), and it was the 2nd successive complete failure. The backoff of 30 seconds is consistent with Airbyte's default retry backoff schedule: [Jobs & Retries] • 10 seconds after the 1st complete failure • 30 seconds after the 2nd ← you are here The job is being retried, not permanently failed yet. By default, Airbyte allows up to 5 successive complete failures and 10 total complete failures before giving up. [Jobs & Retries] The Underlying Problem The knowledge sources do not contain enough information to definitively identify what caused the failure at

04:00:37

from these logs alone. However, given: • 5 GB / 780,000 records were read successfully • The destination flush worker was still active just before • The failure is classified as a complete failure (0 partial failures) This suggests the sync may have crashed before committing any state, meaning all 780K records were read but no checkpoint was saved. Possible causes include: 1. Destination write failure — the remaining 198 records in the queue may not have flushed successfully 2. OOM or resource exhaustion at the destination side after processing 5 GB 3. The original heartbeat timeout from a prior attempt — this may be attempt #3 of an ongoing retry cycle Recommended Next Steps 1. Check logs from earlier attempts (attempts 1 and 2) to find the root cause error message 2. Look for destination-side errors — specifically around

04:00:28–04:00:37

in the destination logs 3. Check destination resource availability — 5 GB of data is substantial and destination resource constraints are a known cause of failures [Heartbeats Docs] 4. The job will automatically retry — monitor whether subsequent attempts succeed or fail at the same record count 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements