@kapa.ai my hubspot connector is stuck for long time, in logs it shows that it is doing sometime, but doesnt do anything 2026-06-02 110516 replication-orchestrator INFO Stream status TRACE received of status: STARTED for stream email_events 2026-06-02 110516 replication-orchestrator INFO Sending update for email_events - null -> RUNNING 2026-06-02 110516 replication-orchestrator INFO Stream Status Update Received: email_events - RUNNING 2026-06-02 110516 replication-orchestrator INFO Creating status: email_events - RUNNING 2026-06-02 110516 replication-orchestrator INFO Stream status TRACE received of status: STARTED for stream email_subscriptions 2026-06-02 110516 replication-orchestrator INFO Sending update for email_subscriptions - null -> RUNNING 2026-06-02 110516 replication-orchestrator INFO Stream Status Update Received: email_subscriptions - RUNNING 2026-06-02 110516 replication-orchestrator INFO Creating status: email_subscriptions - RUNNING 2026-06-02 110516 replication-orchestrator INFO Stream status TRACE received of status: STARTED for stream engagements 2026-06-02 110516 replication-orchestrator INFO Sending update for engagements - null -> RUNNING 2026-06-02 110516 replication-orchestrator INFO Stream Status Update Received: engagements - RUNNING 2026-06-02 110516 replication-orchestrator INFO Creating status: engagements - RUNNING 2026-06-02 110516 replication-orchestrator INFO Stream status TRACE received of status: STARTED for stream engagements_emails 2026-06-02 110516 replication-orchestrator INFO Sending update for engagements_emails - null -> RUNNING 2026-06-02 110516 replication-orchestrator INFO Stream Status Update Received: engagements_emails - RUNNING 2026-06-02 110516 replication-orchestrator INFO Creating status: engagements_emails - RUNNING 2026-06-02 110516 replication-orchestrator INFO Stream status TRACE received of status: STARTED for stream marketing_emails 2026-06-02 110516 replication-orchestrator INFO Sending update for marketing_emails - null -> RUNNING 2026-06-02 110516 replication-orchestrator INFO Stream Status Update Received: marketing_emails - RUNNING 2026-06-02 110516 replication-orchestrator INFO Creating status: marketing_emails - RUNNING 2026-06-02 110516 replication-orchestrator INFO Stream status TRACE received of status: RUNNING for stream campaigns 2026-06-02 110516 source INFO Retrying. Sleeping for 10 seconds 2026-06-02 110516 source INFO Backing off _send(...) for 0.0s (airbyte_cdk.sources.streams.http.exceptions.UserDefinedBackoffException: HubSpot rate limit reached (429). Backoff based on 'Retry-After' header, then exponential backoff fallback.) 2026-06-02 110516 source INFO Retrying. Sleeping for 10 seconds 2026-06-02 110516 source INFO Marking stream companies as RUNNING 2026-06-02 110516 replication-orchestrator INFO Stream status TRACE received of status: RUNNING for stream companies 2026-06-02 110516 destination INFO i.a.c.i.d.r.SerializedBufferingStrategy(lambda$getOrCreateBuffer$0):108 Starting a new buffer for stream campaigns (current state: 0 bytes in 0 buffers) 2026-06-02 110517 destination WARN o.a.h.u.NativeCodeLoader(<clinit>):60 Unable to load native-hadoop library for your platform... using builtin-java classes where applicable 2026-06-02 110517 destination INFO o.a.h.i.c.CodecPool(getCompressor):153 Got brand-new compressor [.snappy] 2026-06-02 110518 destination INFO i.a.c.i.d.r.SerializedBufferingStrategy(lambda$getOrCreateBuffer$0):108 Starting a new buffer for stream companies (current state: 3 KB in 1 buffers) 2026-06-02 110518 source INFO Read 14 records from campaigns stream 2026-06-02 110518 source INFO Marking stream campaigns as STOPPED 2026-06-02 110518 source INFO Finished syncing campaigns 2026-06-02 110518 source INFO Marking stream owners as STARTED 2026-06-02 110518 replication-orchestrator INFO Stream status TRACE received of status: COMPLETE for stream campaigns 2026-06-02 110518 source INFO Syncing stream: owners 2026-06-02 110518 replication-orchestrator INFO Stream status TRACE received of status: STARTED for stream owners 2026-06-02 110518 replication-orchestrator INFO Sending update for owners - null -> RUNNING 2026-06-02 110518 replication-orchestrator INFO Stream Status Update Received: owners - RUNNING 2026-06-02 110518 replication-orchestrator INFO Creating status: owners - RUNNING

HubSpot Connector Appearing Stuck Based on your logs and the available knowledge sources, your connector is not actually stuck — it's actively working, but several factors are making it appear slow or idle. What's happening in your logs 1. Rate limiting (429) — You can see this line clearly:source INFO Backing off _send(...) for 0.0s (airbyte_cdk.sources.streams.http.exceptions.UserDefinedBackoffException: HubSpot rate limit reached (429). Backoff based on 'Retry-After' header, then exponential backoff fallback.) source INFO Retrying. Sleeping for 10 secondsThe connector is hitting HubSpot's rate limits and backing off. HubSpot enforces strict limits — CRM search endpoints are limited to 5 requests/second and 300 requests/minute, while other endpoints allow 10 requests/second. [API Rate Budget] 2. Hidden association API calls — Streams like

engagements_emails

and

companies

make additional batch POST requests to the Associations v4 API for every page of results. For example, the

companies

stream fetches associations for multiple entity types, meaning each page of results costs multiple HTTP requests. This silently multiplies API usage and slows things down. [Hidden API Calls] 3. Destination buffering — The

Starting a new buffer for stream ...

messages in the destination logs are normal. The destination is buffering records before writing them, which can take a long time with large datasets before any output is visible. This is expected behavior. What you can do • Wait it out — The connector is actively retrying with backoff. On busy HubSpot workspaces with large datasets, syncs can take a very long time due to rate limiting. • Reduce the number of streams — If you don't need all streams (e.g.,

engagements

,

engagements_emails

,

email_events

), disabling unused ones will reduce API calls and speed up the sync. • Check your HubSpot API usage — If your workspace is very active, you may be competing with other API consumers for the rate limit budget. • Monitor for actual errors — Your logs show streams completing successfully (e.g.,

campaigns

read 14 records and finished). As long as streams are eventually completing, the sync is progressing normally. In short, the slow progress is most likely a combination of rate limiting and the volume of hidden association API calls — both are known behaviors of the HubSpot connector. [Contributing Guide] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai I only have this connection that uses my huspot api, also this runs in around 30 min somedays, and sometimes infiently stuck

The knowledge sources do not contain enough information to explain definitively why your sync completes in ~30 minutes some days but gets stuck indefinitely on others. However, based on what the knowledge sources do cover, here are the most likely explanations: Why the behavior is inconsistent 1. Rate limiting is non-deterministic — HubSpot's rate limits depend on overall API activity across your account. Even if you're the only Airbyte connection, other tools or HubSpot's own internal processes can consume your API quota, causing the connector to back off for much longer on some days than others. [API Rate Budget] 2. Hidden association API calls multiply unpredictably — Streams like

engagements_emails

and

companies

make additional batch requests per page of results. If HubSpot returns more records on a given day (e.g., new data was added), the number of association API calls increases proportionally, which can push you into rate limiting territory. [Hidden API Calls] 3.

email_events

is a known heavy stream — This stream can pull a very large volume of records and is specifically called out as a performance concern due to HubSpot API limitations. [Forum Post] Suggestions • Set a more recent

start_date

— If your

start_date

is far in the past, the connector may be re-scanning a large historical window on some syncs. A more recent start date limits the scope. • Disable streams you don't need — Particularly

email_events

,

engagements

, and

engagements_emails

if not required, as these are among the heaviest streams. • Check if the sync is truly stuck vs. just slow — Look for continued

Retrying. Sleeping for X seconds

messages in the logs. If those are still appearing, the connector is alive but rate-limited. If there are no log messages at all for a long period, it may be a genuine hang. I'd recommend opening a GitHub issue with your connector version and full logs if the indefinite stalls continue, as this intermittent behavior may warrant deeper investigation by the Airbyte team. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai do i need to increase any resources

Based on your situation — a single HubSpot connection that sometimes completes in 30 minutes — resource constraints are unlikely to be the primary cause of your issue. The rate limiting (429 errors) visible in your logs points to HubSpot API throttling rather than insufficient compute resources. That said, the knowledge sources do note some resource-related things worth checking: When resources could help • If your deployment is under-provisioned, you may see occasional stuck jobs that remain in-progress for long periods. [Scaling Guide] • The source worker reads up to 10,000 records in memory at a time. If your HubSpot streams have large row sizes, this could cause memory pressure. [Scaling Airbyte] How to check Use an infrastructure monitoring tool to measure: • CPU Usage % vs Requested CPU % • Memory Usage % vs Requested Memory % If used CPU/memory is low but the sync is still stuck, increasing resources likely won't help. [Scaling Guide] Bottom line Since your sync does complete successfully on some days, this strongly suggests the root cause is HubSpot rate limiting, not resource starvation. I'd focus on reducing the number of streams or adjusting your

start_date

before investing in more resources. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai if you see it didnt do anything for long time 2026-06-02 110527 destination INFO i.a.c.i.d.r.SerializedBufferingStrategy(lambda$getOrCreateBuffer$0):108 Starting a new buffer for stream contacts (current state: 3 MB in 3 buffers) 2026-06-02 110527 destination INFO o.a.h.i.c.CodecPool(getCompressor):153 Got brand-new compressor [.snappy] 2026-06-02 110838 destination INFO i.a.c.i.d.r.SerializedBufferingStrategy(lambda$getOrCreateBuffer$0):108 Starting a new buffer for stream deal_pipelines (current state: 39 MB in 4 buffers) 2026-06-02 110838 destination WARN i.a.c.i.d.s.a.JsonToAvroSchemaConverter(getAvroSchema):142 Schema name "stages.items" contains illegal character(s) and is standardized to "stages_items" 2026-06-02 110838 destination INFO o.a.h.i.c.CodecPool(getCompressor):153 Got brand-new compressor [.snappy] 2026-06-02 110840 destination INFO i.a.c.i.d.r.SerializedBufferingStrategy(lambda$getOrCreateBuffer$0):108 Starting a new buffer for stream deals (current state: 40 MB in 5 buffers) 2026-06-02 110840 destination INFO o.a.h.i.c.CodecPool(getCompressor):153 Got brand-new compressor [.snappy] 2026-06-03 092503 destination INFO i.a.c.i.d.b.BufferedStreamConsumer(periodicBufferFlush):258 Periodic buffer flush started 2026-06-03 092503 destination INFO i.a.c.i.d.r.SerializedBufferingStrategy(flushAllBuffers):132 Flushing all 6 current buffers (41 MB in total) 2026-06-03 092503 destination INFO i.a.c.i.d.r.SerializedBufferingStrategy(flushAllBuffers):136 Flushing buffer of stream contacts (13 MB) 2026-06-03 092503 destination INFO i.a.c.i.d.s.S3ConsumerFactory(lambda$flushBufferFunction$2):119 Flushing buffer for stream contacts (13 MB) to storage 2026-06-03 092504 destination INFO i.a.c.i.d.s.p.ParquetSerializedBuffer(flush):115 Finished writing data to 592a5b82-db26-4d5e-8dcb-3cea6c09217215051778950185356903.parquet (13 MB) 2026-06-03 092505 destination INFO a.m.s.StreamTransferManager(getMultiPartOutputStreams):329 Initiated multipart upload to prod-datagol-catalog/datagol/datagol_hubspot_new_wh/contacts/2026_06_02_1780412710076_0.parquet with full ID ABPnzm6nCZCyAnyOopJN_X-AaBjxwwqLkVF59bZOX5Fh1J9NcAn0E4uWiWDCYwfVIvux_10 2026-06-03 092505 destination INFO a.m.s.MultiPartOutputStream(close):158 Called close() on [MultipartOutputStream for parts 1 - 10000] 2026-06-03 092505 destination INFO a.m.s.StreamTransferManager(complete):367 [Manager uploading to prod

This is a very clear sign of what's happening. Looking at your logs:

2026-06-02 11:08:40 - Starting a new buffer for stream deals
...
2026-06-03 09:25:03 - Periodic buffer flush started

That's a gap of over 22 hours with no activity — the destination was just holding data in memory buffers (41 MB across 6 streams) waiting for more data from the source. What this means The destination was not stuck — it was waiting for the source to finish reading. The source (

contacts

,

deals

, etc.) was taking extremely long to pull data from HubSpot, most likely due to: 1. Rate limiting — As seen earlier in your logs with the 429 errors and backoff retries 2. Hidden association API calls — The

contacts

and

deals

streams make additional batch API calls per page of results, multiplying the number of requests significantly [Contributing Guide] The good news The sync did eventually complete — the buffer flushed successfully and uploaded to S3/parquet at

09:25:03

on June 3rd. So it wasn't truly stuck, just very slow. What you should do • Disable

contacts

and

deals

association fetching if you don't need association data — these are the heaviest streams due to the hidden API calls • Check how many records are in your HubSpot

contacts

and

deals

— if you have millions, long syncs are expected • Consider splitting contacts/deals into a separate connection from lighter streams, so heavy streams don't block everything else The knowledge sources do not contain enough information to tell you exactly why it completes in 30 minutes on some days — but on the day shown in your logs, the sheer volume of API calls for

contacts

and

deals

appears to be the bottleneck. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai i went into the logs at 9:25 today then it started showing logs at 9:25 or else it would not have shown

That's an important clarification. So the sync was not actually running for 22 hours — it appears the logs only started showing because you opened/checked them at 9:25, and the system began logging from that point. What this likely means The sync was probably genuinely stuck between

11:08:40

on June 2nd and when you checked at

09:25

on June 3rd, with no actual progress happening during that time. This aligns with the intermittent "infinitely stuck" behavior you described earlier. Unfortunately The knowledge sources do not contain enough information to tell me definitively why the sync hangs indefinitely in some runs but completes in 30 minutes in others. This appears to be an intermittent issue that may require deeper investigation. What I'd recommend 1. Open a GitHub issue on the Airbyte repository with: ◦ Your connector versions (source-hubspot and destination version) ◦ Full logs from both a successful 30-min run and a stuck run ◦ Number of records in your

contacts

and

deals

streams 1. As a workaround, set a sync timeout so that stuck syncs are automatically cancelled and retried rather than hanging indefinitely 2. Try disabling heavy streams like

contacts

,

deals

,

engagements

one at a time to identify which stream is causing the hang 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai will increasing resources help

Based on your specific situation, increasing resources is unlikely to fix the indefinite stalling you're experiencing, for these reasons: Why resources probably aren't the issue • Your sync completes successfully in ~30 minutes on some days — this means your current resources are sufficient to run the sync normally • The problem is intermittent, not consistent — a resource shortage would typically cause consistent slowness, not random infinite hangs • Your logs show the source hitting HubSpot 429 rate limits, which is an API-level constraint that more CPU/memory cannot solve When resources would help According to the Airbyte docs, increasing resources makes sense when: • Your nodes are under consistently high CPU or memory usage • You see frequent OOM (out of memory) errors in logs • Syncs are slow every time, not just intermittently [Scaling Guide] What to check first Before increasing resources, use an infrastructure monitoring tool to measure CPU and memory usage during a stuck sync. If usage is low while the sync is stuck, more resources won't help. [Scaling Guide] Bottom line The intermittent nature of your issue points more toward a HubSpot API or connector-level problem rather than infrastructure constraints. I'd recommend filing a GitHub issue with your logs before spending on additional resources. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai see i stopped and started again stuck since 5 min 2026-06-03 093744 source INFO Marking stream deals as STOPPED 2026-06-03 093744 source INFO Finished syncing deals 2026-06-03 093744 replication-orchestrator INFO Stream status TRACE received of status: COMPLETE for stream deals 2026-06-03 093744 source INFO Marking stream email_events as RUNNING 2026-06-03 093744 replication-orchestrator INFO Stream status TRACE received of status: RUNNING for stream email_events 2026-06-03 093747 destination INFO i.a.c.i.d.r.SerializedBufferingStrategy(lambda$getOrCreateBuffer$0):108 Starting a new buffer for stream email_events (current state: 35 MB in 6 buffers) 2026-06-03 093747 destination WARN i.a.c.i.d.s.a.JsonToAvroSchemaConverter(parseSingleType):260 Array field "cc" does not specify the items type. It will default to an array of strings 2026-06-03 093747 destination WARN i.a.c.i.d.s.a.JsonToAvroSchemaConverter(parseSingleType):260 Array field "bcc" does not specify the items type. It will default to an array of strings 2026-06-03 093747 destination WARN i.a.c.i.d.s.a.JsonToAvroSchemaConverter(getAvroSchema):142 Schema name "subscriptions.items" contains illegal character(s) and is standardized to "subscriptions_items" 2026-06-03 093747 destination INFO o.a.h.i.c.CodecPool(getCompressor):153 Got brand-new compressor [.snappy] 2026-06-03 093751 replication-orchestrator INFO Records read: 5000 (238 MB) 2026-06-03 093808 replication-orchestrator INFO Records read: 5000 (270 MB) 2026-06-03 093818 replication-orchestrator INFO Records read: 5000 (297 MB) 2026-06-03 093838 replication-orchestrator INFO Records read: 5000 (317 MB) 2026-06-03 093851 replication-orchestrator INFO Records read: 5000 (330 MB) 2026-06-03 093900 replication-orchestrator INFO Records read: 5000 (359 MB) 2026-06-03 093915 source INFO Marking stream email_subscriptions as RUNNING 2026-06-03 093915 replication-orchestrator INFO Stream status TRACE received of status: RUNNING for stream email_subscriptions 2026-06-03 093915 source INFO Read 2 records from email_subscriptions stream 2026-06-03 093916 destination INFO i.a.c.i.d.r.SerializedBufferingStrategy(lambda$getOrCreateBuffer$0):108 Starting a new buffer for stream email_subscriptions (current state: 60 MB in 7 buffers) 2026-06-03 093916 destination INFO o.a.h.i.c.CodecPool(getCompressor):153 Got brand-new compressor [.snappy]

Looking at these logs, your sync is actually not stuck — it's actively working:

09:37:51 - Records read: 5000 (238 MB)
09:38:08 - Records read: 5000 (270 MB)
09:38:18 - Records read: 5000 (297 MB)
09:38:38 - Records read: 5000 (317 MB)
09:38:51 - Records read: 5000 (330 MB)
09:39:00 - Records read: 5000 (359 MB)

The real problem — email_events This stream is reading 5,000 records every 10-20 seconds and already at 359 MB in under 2 minutes. This is a known heavy stream. [Forum Post] • It has a very large volume of records • Each batch of 5,000 records is ~30-40 MB, meaning your total dataset is likely gigabytes • The destination buffer is already at 60 MB across 7 streams and growing fast This is why your sync sometimes takes 30 min and sometimes "hangs" • On days with less

email_events

data to process → completes in 30 min • On days with more data or rate limiting → runs for hours and appears stuck Strong recommendation Disable

email_events

if you don't absolutely need it. It is specifically called out as a performance concern due to HubSpot API limitations and high data volume. [Forum Post] If you do need it, consider setting a more recent

start_date

to limit how far back it reads. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai Syncing campaigns 14 extracted | 44m elapsed - Syncing companies 10,072 extracted | 44m elapsed - Syncing contact_lists 21 extracted | 44m elapsed - Syncing contacts 7,999 extracted | 44m elapsed - Syncing deal_pipelines 1 extracted | 44m elapsed - Queued deals Starting… | 44m elapsed - Queued email_events Starting… | 44m elapsed - Queued email_subscriptions Starting… | 44m elapsed - Queued engagements Starting… | 44m elapsed - Queued engagements_emails Starting… | 44m elapsed - Queued marketing_emails Starting… | 44m elapsed - Queued owners i think some issue with deal pipleins alsways stucks there

Looking at your sync status, the issue is actually with

contacts

— not

deal_pipelines

. What the numbers tell us

deal_pipelines

only extracted 1 record — it's actually done. Everything after it is queued waiting for

contacts

and

companies

to finish. Why contacts is slow

contacts

is one of the heaviest streams because: • It makes additional hidden batch API calls to the Associations v4 API for every page of results [Contributing Guide] • With 7,999 records still counting at 44 minutes, it's likely hitting HubSpot rate limiting (429) between pages What to do 1. Wait —

contacts

and

companies

are still actively syncing, everything else will unqueue once they finish 2. Long term — If

contacts

consistently takes this long, consider whether you need all association data, as each page triggers multiple extra API calls [Contributing Guide] 👍 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

@kapa.ai what streams do you want me to avaoid for ruuning now, so after some complete i can trigger them

Based on your current sync status and what the knowledge sources tell us about heavy streams, here's what I'd suggest: Keep running now (light streams) •

campaigns

✅ already done •

contact_lists

✅ already done •

deal_pipelines

✅ already done •

owners

— very small, fast •

email_subscriptions

— only 2 records seen earlier Let finish, then trigger separately •

companies

— still running, 10,072 records, let it complete first •

contacts

— still running, 7,999 records, let it complete first Trigger separately after current sync completes These are the heaviest streams — run them in a separate sync or one at a time: 1.

email_events

— extremely high volume, can run for hours [Forum Post] 2.

engagements

— heavy stream with many association API calls [Contributing Guide] 3.

engagements_emails

— same issue, hidden association calls per page [Contributing Guide] 4.

deals

— moderate volume but also has association calls for companies, contacts, and line items [Contributing Guide] 5.

marketing_emails

— makes one extra API call per individual record for statistics [Contributing Guide] Practical approach Consider creating two separate Airbyte connections to the same HubSpot source: • Connection 1 — light streams (campaigns, contact_lists, owners, etc.) • Connection 2 — heavy streams (email_events, engagements, deals, marketing_emails) on a less frequent schedule 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

looks like issue with the contact stream all others completed when ran separelty @kapa.ai

That confirms it —

contacts

is your problem stream. This is actually a well-documented issue in the knowledge sources. Why contacts specifically struggles 1. Hidden association API calls — For every page of contacts, the connector makes additional batch POST requests to HubSpot's Associations v4 API. So each page of 100 contacts actually costs multiple HTTP requests [Contributing Guide] 2. Known mid-sync auth failures — There is a documented bug where OAuth tokens expire mid-sync specifically during the associations read for the

contacts

stream, causing it to hang or fail. This was fixed in version

5.8.11

[GitHub Issue] 3. Incremental sync issues — There was also a documented bug where

contacts

would pull all records instead of only updated ones since the last bookmark, fixed in version

6.1.1

[GitHub Issue] What to check immediately • What version of

source-hubspot

are you on? If you're below

6.1.1

, upgrading should help significantly • If you're already on a recent version, the associations read is likely causing rate limiting Quick workaround right now Run

contacts

in its own dedicated separate connection away from all other streams, so when it hangs it doesn't block everything else. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

i am on 6.0.15 @kapa.ai

Version

6.0.15

is below

6.1.1

where the key fixes were applied. This is very likely the root cause of your

contacts

stream issues. Fixes you are missing on 6.0.15 What's likely happening to you On

6.0.15

, the

contacts

stream is probably: • Pulling all records every sync instead of only updated ones since the last bookmark • Potentially failing mid-sync due to OAuth token expiration during association reads What to do Upgrade to

6.1.1

or later immediately — this single step is very likely to fix your contacts stream hanging issue. The upgrade should result in: • Faster incremental syncs • No more mid-sync auth failures on associations 👍 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

Sorry @Srikar Chamarthy, I'm not sure what you mean. Please try again. 👋

@kapa.ai these are the versions

It looks like you forgot to attach the screenshot or list of versions! Could you please share them? That way I can compare your current versions against the known fixes and give you specific upgrade recommendations. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai contacts also when run spearelty worked

That's actually a really useful data point! If

contacts

completes successfully when run separately (in its own connection), it tells us: The issue is not contacts itself The problem is resource/API contention when

contacts

runs alongside other streams: • When running with other streams,

contacts

competes for HubSpot's rate limit budget — the 429 errors you saw earlier are shared across all streams running concurrently [Contributing Guide] •

contacts

makes hidden association API calls on top of the primary read, multiplying its API usage significantly [Contributing Guide] • When other streams consume the rate limit,

contacts

backs off repeatedly and eventually appears stuck Recommended setup going forward Split into two separate Airbyte connections: Connection 1 — Run alone •

contacts

Connection 2 — Run together •

campaigns

,

contact_lists

,

deal_pipelines

,

owners

,

companies

,

deals

,

email_subscriptions

,

marketing_emails

Connection 3 — Run separately (heaviest) •

email_events

,

engagements

,

engagements_emails

And schedule them to run at different times so they don't overlap and compete for HubSpot's API rate limit. Also, upgrading to

6.1.1

is still strongly recommended as it fixes incremental sync issues that may be causing

contacts

to pull more records than necessary each run. [GitHub Issue] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai i am doing full refresh though

That's an important detail. Since you're using Full Refresh, the incremental sync fixes in

6.1.1

won't help you directly — Full Refresh always pulls all records regardless. What this means for your situation With Full Refresh: • Every sync pulls all records from scratch — so

contacts

will always read all 7,999+ records every time • The version upgrade fixes won't reduce the amount of data being pulled • The rate limiting problem remains — more records = more API calls = more 429 backoffs Why it worked when run separately This confirms the issue is purely HubSpot API rate limit contention: • When

contacts

runs alone, it gets the full rate limit budget to itself • When running with other streams, it has to share the budget and backs off repeatedly, appearing stuck Recommendations 1. Keep the separate connection approach — this is the most practical fix for your situation right now, since Full Refresh will always be heavy for

contacts

2. Consider switching

contacts

to Incremental sync if possible — this would dramatically reduce the number of records pulled on each sync after the first one [GitHub Issue] 3. Schedule syncs at off-peak hours — when HubSpot API usage is lower, you're less likely to hit rate limits The knowledge sources do not contain enough information to tell me exactly what rate limit budget HubSpot allocates, but splitting connections remains your best practical solution. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.