Hi @kapa.ai My google ads source to clickhouse destination connector started to act weird last 20 days it was supposed to run each day but for some reason it syncs everything but doesn’t close the connection waits forever then after 20 days it throw an error “Airbyte detected that the Source didn’t send any records in the last 1 day 0 hours 2 minutes 25 seconds, exceeding the configured 1 day threshold. Airbyte will try reading again on the next sync. Please see https://docs.airbyte.com/understanding-airbyte/heartbeats for more info.” “Last record seen 1 day 0 hours 2 minutes 25 seconds ago, exceeding the threshold of 1 day.” A new sync started today, completed updating around 1.5m records so far, and is stuck for the last 7 hours logging nothing “2026-02-16 105950 replication-orchestrator INFO Records read: 1460000 (1 GB) 2026-02-16 105958 destination INFO pool-2-thread-1 i.a.c.l.d.a.AggregateStore(removeNextComplete):43 PUBLISH — Reason: Complete 2026-02-16 105958 destination INFO DefaultDispatcher-worker-2 i.a.i.d.c.w.l.BinaryRowInsertBuffer(flush):59 Beginning insert into google_ads_raw_location_user_location_stats 2026-02-16 105958 destination INFO DefaultDispatcher-worker-2 i.a.i.d.c.w.l.BinaryRowInsertBuffer(flush):70 Finished insert of 117614 rows into google_ads_raw_location_user_location_stats 2026-02-16 110003 replication-orchestrator INFO Records read: 1465000 (1 GB) 2026-02-16 110015 replication-orchestrator INFO Records read: 1470000 (1 GB) 2026-02-16 110026 replication-orchestrator INFO Records read: 1475000 (1 GB) 2026-02-16 110037 replication-orchestrator INFO Records read: 1480000 (1 GB) 2026-02-16 110049 replication-orchestrator INFO Records read: 1485000 (1 GB) 2026-02-16 110100 replication-orchestrator INFO Records read: 1490000 (1 GB) 2026-02-16 110112 replication-orchestrator INFO Records read: 1495000 (1 GB) 2026-02-16 110122 source INFO Marking stream keyword_view as STARTED 2026-02-16 110122 source INFO Syncing stream: keyword_view 2026-02-16 110122 replication-orchestrator INFO Stream status TRACE received of status: STARTED for stream keyword_view 2026-02-16 110122 replication-orchestrator INFO Sending update for keyword_view - null -> RUNNING 2026-02-16 110122 replication-orchestrator INFO Stream Status Update Received: keyword_view - RUNNING 2026-02-16 110122 replication-orchestrator INFO Creating status: keyword_view - RUNNING 2026-02-16 110124 source INFO Marking stream campaign_budget as RUNNING 2026-02-16 110124 replication-orchestrator INFO Stream status TRACE received of status: RUNNING for stream campaign_budget 2026-02-16 110124 replication-orchestrator INFO Records read: 1500000 (1 GB) 2026-02-16 110124 destination INFO pool-2-thread-1 i.a.c.l.d.i.JsonDestinationMessageInputFlow(collect):41 Processed 1500000 messages (1221Mb) 2026-02-16 110134 replication-orchestrator INFO Records read: 1505000 (1 GB) 2026-02-16 110145 replication-orchestrator INFO Records read: 1510000 (1 GB) 2026-02-16 110156 replication-orchestrator INFO Records read: 1515000 (1 GB) 2026-02-16 110208 replication-orchestrator INFO Records read: 1520000 (1 GB) 2026-02-16 110219 replication-orchestrator INFO Records read: 1525000 (1 GB) 2026-02-16 110222 source INFO Read 11718 records from campaign_budget stream 2026-02-16 110222 source INFO Marking stream campaign_budget as STOPPED 2026-02-16 110222 source INFO Finished syncing campaign_budget 2026-02-16 110222 replication-orchestrator INFO Stream status TRACE received of status: COMPLETE for stream campaign_budget 2026-02-16 110226 source INFO Marking stream campaign as STARTED 2026-02-16 110226 source INFO Syncing stream: campaign 2026-02-16 110226 replication-orchestrator INFO Stream status TRACE received of status: STARTED for stream campaign 2026-02-16 110226 replication-orchestrator INFO Sending update for campaign - null -> RUNNING 2026-02-16 110226 replication-orchestrator INFO Stream Status Update Received: campaign - RUNNING 2026-02-16 110226 replication-orchestrator INFO Creating status: campaign - RUNNING 2026-02-16 110230 replication-orchestrator INFO Records read: 1530000 (1 GB)”

There’s partial information in the knowledge sources about what you’re seeing (heartbeats / “source unresponsive”), but nothing that exactly matches your Google Ads → ClickHouse behavior, so I’ll focus on what is documented and where the gaps are. ### What the error means The message: > “Airbyte detected that the Source didn’t send any records in the last 1 day … exceeding the configured 1 day threshold…” comes from Airbyte’s heartbeat mechanism. Airbyte monitors

RECORD

and

STATE

messages from the source; if no message is seen for longer than the configured threshold, the platform marks the source as unresponsive and fails (or restarts) the sync. [[Heartbeats tech](https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details)] By default: -

heartbeat-max-seconds-between-messages

is 3 hours, but in your case it’s clearly been configured to 1 day. [[Heartbeats tech](https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details)] - If

heartbeat.failSync

is

true

, the sync is failed when this threshold is exceeded. [[Heartbeats tech](https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details)] So your job is “stuck” in the sense that: 1. The Google Ads source stops emitting messages (no `RECORD`/`STATE`), but 2. The platform keeps the job running until the heartbeat timeout (1 day) is hit, then logs the error you see. ### Why this often happens with API sources The docs call out that API sources can be slow or blocked for long periods (rate limits, async processing, etc.), and that this is a known cause of heartbeat errors. [[Heartbeats causes](https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#known-heartbeat-error-causes)] For Google Ads specifically, there are a few related issues in the knowledge sources: - Large datasets / complex date chunking in Google Ads can cause long-running slices and timeouts. [[Google Ads timeout](https://github.com/airbytehq/airbyte/issues/49254)] - Some Google Ads streams (e.g.

click_view

) have had stability problems after connector changes, leading to repeated failures and partial loads. [[click_view failures](https://github.com/airbytehq/airbyte/issues/63739)] - A later version of the Google Ads connector had syncs that “hang for many hours” after a change to streaming APIs; the workaround there was to pin to an earlier connector version. [[403 hang](https://github.com/airbytehq/airbyte/issues/72820)] None of these exactly match your logs, but they show that: - Google Ads streams with large volumes can get into long, opaque waits. - Connector version changes can introduce hanging behavior. ### What you can concretely check / try Based on the docs and issues (and staying within what’s documented): 1. Check / adjust heartbeat configuration In your Airbyte deployment, inspect

flags.yaml

and look for: -

heartbeat-max-seconds-between-messages

-

heartbeat.failSync

You can increase

heartbeat-max-seconds-between-messages

if you know the Google Ads source legitimately needs long periods without emitting records, or temporarily set

heartbeat.failSync: false

to avoid failing the sync on missed heartbeats (it will still log the issue). [[Heartbeats tech](https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details)] Be aware this only masks the symptom (the long pause); it doesn’t fix the underlying cause. 2. Check Google Ads connector version and known issues The knowledge sources show that: - v3.13.0+ introduced issues for

click_view

. [[click_view failures](https://github.com/airbytehq/airbyte/issues/63739)] - v4.1.4 had hanging behavior related to streaming; users pinned back to 4.0.2 as a workaround. [[403 hang](https://github.com/airbytehq/airbyte/issues/72820)] If you recently upgraded the Google Ads connector around the time this started (last ~20 days), it’s plausible you’ve hit a similar regression. The documented workaround in such cases is to pin to a previously stable connector version. 3. Consider data volume / slicing One open issue shows that for

shopping_performance_view

, reducing the slice duration (smaller date chunks) avoided timeouts. [[Google Ads timeout](https://github.com/airbytehq/airbyte/issues/49254)] The knowledge sources only mention this as a code-level change and a user request to make

slice_duration

configurable; they do not document a UI setting for it. So I can’t tell you exactly how to tune this from the UI, only that large slices are a known problem area for Google Ads. 4. Avoid overly frequent syncs for Google Ads In another Google Ads thread, support recommended daily syncs instead of intra-day, because if the API returns “no data yet” for a period, incremental syncs can permanently miss that data. [[Google Ads yesterday](https://discuss.airbyte.io/t/922)] This doesn’t directly explain your hang, but if you’re running very frequent syncs, it may be worth simplifying to a once-per-day schedule while you debug. ### What’s not covered in the docs - There is no explicit documentation tying Google Ads + ClickHouse + your specific streams (

keyword_view

,

campaign

, etc.) to a known “stuck for many hours then heartbeat error” bug. - There is no documented configuration knob on the ClickHouse destination that would explain this behavior. - There is no step-by-step fix for your exact log pattern. Given that, the most defensible next steps, grounded in the docs, are: 1. Verify and, if needed, relax the heartbeat settings in

flags.yaml

. [[Heartbeats tech](https://docs.airbyte.com/platform/understanding-airbyte/heartbeats#technical-details)] 2. Check your Google Ads connector version and, if the issue started after an upgrade, test by pinning back to a version that was stable for you (similar to the workaround in the 4.1.4 issue). [[403 hang](https://github.com/airbytehq/airbyte/issues/72820)] 3. If possible, reduce the data volume per sync (fewer streams, shorter date ranges) to see if the long silent period disappears, which would support the “large slice / long API wait” hypothesis. [[Google Ads timeout](https://github.com/airbytehq/airbyte/issues/49254)] 4. If the problem persists, collect full logs from a failing run and open a GitHub issue for

source-google-ads

, referencing the heartbeat behavior and your connector version, so the team can reproduce it (this is how the other Google Ads issues were handled). [[click_view failures](https://github.com/airbytehq/airbyte/issues/63739)] If you can share your Google Ads connector version and whether this started right after an upgrade, I can help you map that against the known issues in the sources above.