@kapa.ai the HubSpot to Bigquery sync for the contacts_web_analytics is stuck in the RUNNING for stream contacts_web_analytics it is loading 10 - 15 rows to airbyte internal table but hasn't finished the sync yet its been 16 hrs

There are several known issues with HubSpot → BigQuery syncs getting stuck, and your situation shares characteristics with multiple reported cases. However, the knowledge sources do not contain specific information about the

contacts_web_analytics

stream in particular, so I'll share what's relevant based on similar patterns. What's Likely Happening Based on similar reported issues, a few possible causes: 1. Sync stuck in a retry loop — The destination-bigquery connector may be loading small batches (10–15 rows) to the

airbyte_internal

table but failing to commit checkpoints, causing it to retry the same data repeatedly without advancing. [BigQuery Retry Loop Issue] 2. SourceReader hanging after destination failure — If BigQuery returns a 400/500 error, the

SourceReader

can sometimes keep running indefinitely because blocking socket reads are not interruptible by coroutine cancellation. [SourceReader Hang Issue] 3. BigQuery job wait timeout — The

waitForJobFinish

method in the BigQuery destination has a 30-minute timeout per job. If jobs are repeatedly failing and retrying, the sync can appear stuck for many hours. [BigQueryUtils source] Recommended Steps 1. Check your logs for BigQuery errors — Look for messages like: ◦

400 Bad Request

/

invalid euc header

(auth token expiry) ◦

500 Internal Server Error

◦

No checkpoints to flush

repeated many times 1. Cancel and retry the sync — Cancelling often unblocks the sync, as the next attempt starts fresh. [Sync Hangs Forum] 2. Check your connector versions — Make sure you're on a recent version of both

source-hubspot

(v6.1.1+) and

destination-bigquery

(3.0.1+). Several incremental sync and checkpointing bugs were fixed in recent versions. [HubSpot Incremental Fix] 3. Consider upgrading to BigQuery destination 3.0.1+ — The newer Direct Load paradigm avoids some of the long-running resumable upload issues that cause auth token expiry. [BigQuery Migration] 4. Set a sync timeout — If you're self-hosting, you can configure

SYNC_JOB_MAX_TIMEOUT_DAYS

in your

.env

to prevent syncs from hanging indefinitely (minimum is 1 day). [Timeout Config] If the issue persists after cancelling and retrying, I'd recommend opening a GitHub issue with your connector versions and relevant log snippets, as the

contacts_web_analytics

stream behavior isn't specifically documented in the available knowledge sources. 👍 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 there's is no issue from the BQ side, its loading small data chunks at very low speed while the other main streams contacts and deals loaded perfectly and speedy manner

Based on the knowledge sources, I can explain why

contacts_web_analytics

is likely much slower than the main

contacts

and

deals

streams. Why contacts_web_analytics Is Slow The

contacts_web_analytics

stream uses a SubstreamPartitionRouter with

contacts

as the parent stream. This means it must: 1. Iterate over every contact record individually — it fetches web analytics events per contact ID, one partition at a time 2. Cross that with a ListPartitionRouter for event types (

e_visited_page

,

e_submitted_form

) So if you have, say, 500K contacts, the connector is essentially making web analytics API calls per contact × per event type. This results in an enormous number of API requests compared to the bulk CRM search approach used by

contacts

and

deals

. [manifest.yaml] What You Can Do 1. Be patient — if you have a large number of contacts, this stream is inherently slow by design due to the per-contact partitioning. 16 hours may not be unusual for large accounts. 2. Reduce scope — if you don't need all event types or all contacts' web analytics, consider whether this stream is truly necessary for your use case. 3. Check if it's actually progressing — look at the logs to confirm the partition cursor is advancing (contact IDs being processed), even if slowly. As long as it's moving, it's not stuck. The knowledge sources do not contain specific benchmarks or a known fix for

contacts_web_analytics

performance, so I'd recommend opening a GitHub issue if the sync appears completely stalled with no partition progress. 👍 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 logs shows Read 193381 records from contacts stream how much time it might require to finish syncing the contacts web analytics stream?

I'm sorry, but the knowledge sources do not contain enough information to give you a reliable time estimate for completing the

contacts_web_analytics

sync. However, based on what we know about how the stream works, here's why estimating is difficult: Why a Time Estimate Is Hard The total API calls required are approximately:

193,381 contacts × 2 event types × ceil(date_range / 30 days) = total API requests

For example, if your date range covers 12 months (~12 windows of 30 days):

193,381 × 2 × 12 = ~4.6 million API requests

The actual time depends on factors the knowledge sources don't quantify: • HubSpot API rate limits — how aggressively the connector is throttled • How many events exist per contact — empty responses are fast, paginated ones are slower • Network latency between Airbyte and HubSpot's API What You Can Do 1. Check log progress — look for how many contact partitions have been processed so far vs. 193,381 total. That gives you a rough % complete. 2. Estimate from elapsed time — if after 16 hours you've processed X contacts, divide 193,381 by X to extrapolate remaining time. 3. Consider narrowing the

start_date

— a shorter date range dramatically reduces the number of API calls per contact. [manifest.yaml] 👍 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 here i found the relevant stats from logs : status=JobStatus{state=DONE, error=null, executionErrors=null}, statistics=LoadStatistics{creationTime=1785392565241, endTime=1785392566748, startTime=1785392565389, numChildJobs=null, parentJobId=null, scriptStatistics=null, reservationUsage=null, transactionInfo=null, sessionInfo=null, totalSlotMs=4992, inputBytes=37253, inputFiles=1, outputBytes=29079, outputRows=39, badRecords=0} how can i get how many contacts has been processed

The knowledge sources do not contain enough information to give you a precise method to extract per-contact partition progress from BigQuery load job stats. However, based on what your log snippet shows: What Your Log Stats Tell You The BigQuery job stats you shared show per-batch loading metrics: •

outputRows=39

— only 39 rows loaded in this particular batch •

inputBytes=37253

(~36 KB) — very small batch • Job completed in ~1.3 seconds (

endTime - startTime

) This confirms the stream is loading very small chunks per API call, which is consistent with the per-contact partitioning behavior described earlier. How to Estimate Contacts Processed The logs themselves won't directly tell you how many contacts have been processed from the BigQuery side. Instead, you should look at the Airbyte source logs, not the BigQuery destination logs. Specifically look for lines like:

INFO Syncing stream: contacts_web_analytics
INFO slice: {"contactId": "12345", ...}

or record count lines like:

INFO Read X records from contacts_web_analytics stream

Practical Suggestion Rather than estimating from BigQuery stats, I'd recommend: 1. Search your Airbyte logs for

contacts_web_analytics

partition/slice progress messages 2. Count total rows in your BigQuery

airbyte_internal

table for

contacts_web_analytics

and divide by your average records per contact to estimate progress Unfortunately, the knowledge sources do not contain specific log format details for

contacts_web_analytics

partition-level progress reporting. 👍 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 following log is what i have from the source 2026-07-30 001728 source INFO Read 193381 records from contacts stream 2026-07-30 010152 source INFO Marking stream contacts as STOPPED 2026-07-30 010152 source INFO Finished syncing contacts 2026-07-30 011153 source INFO Marking stream contacts_web_analytics as RUNNING 2026-07-30 063758 source INFO Exceeded the 'SWITCH_TO_GLOBAL_LIMIT' of 10000. Switching to global cursor for contacts_web_analytics.

This is very useful information! Here's what your logs reveal: What the Logs Tell Us Timeline So Far So

contacts_web_analytics

has been running for ~5.5 hours before switching to global cursor, and is still going. What the Global Cursor Switch Means The critical log line is:

Exceeded the 'SWITCH_TO_GLOBAL_LIMIT' of 10000. Switching to global cursor for contacts_web_analytics.

This means the stream processed 10,000 contact partitions before switching from per-partition state to a single global cursor. This is expected behavior — the default per-partition state has a hard limit of 10,000 partitions, after which it falls back to a global cursor to manage efficiency. [Incremental Sync Docs] The Concerning Part You have 193,381 contacts but the per-partition limit is 10,000. This means: • Only ~5% of contacts were tracked individually • The remaining ~183,381 contacts are now being processed under a global cursor • The global cursor is only updated at the end of the sync, meaning if the sync fails, you may need to re-process a large portion of data Time Estimate The knowledge sources do not provide enough detail to give a precise estimate, but roughly: • 10,000 partitions took ~5.5 hours • Remaining ~183,381 contacts at the same rate could take significantly longer However, the global cursor mode may be faster since it reduces state management overhead. Recommendation For future syncs, consider setting a narrower

start_date

in your HubSpot source configuration to reduce the number of API calls per contact partition, which would significantly speed up this stream. [manifest.yaml] 👍 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 airbyte - internal shows only 390 table rows for Hubspotcontactsnalytics. while hubspotcontacts table has 193381 rows

The knowledge sources do not contain enough specific information to fully explain this discrepancy, but based on what we know about how

contacts_web_analytics

works, here's what's likely happening: Why Only 390 Rows vs 193,381 Contacts 1. Not All Contacts Have Web Analytics Events The

contacts_web_analytics

stream only returns records where actual web analytics events exist (

e_visited_page

,

e_submitted_form

). If a contact has never visited a tracked page or submitted a form, they produce zero rows. So 390 rows doesn't mean only 390 contacts were processed — it means only 390 events have been found so far. [manifest.yaml] 2. The Sync Is Still Running Based on your earlier logs, the stream only switched to global cursor at

06:37:58

and is still processing. The

airbyte_internal

table will only reflect batches committed so far — more rows will appear as processing continues. 3. Small Batch Sizes Your earlier BigQuery stats showed batches of only 39 rows at a time, which explains the slow accumulation in

airbyte_internal

. What to Do • Don't cancel the sync — it is still actively processing contacts under the global cursor • Monitor row count growth in

airbyte_internal

periodically to confirm it's still increasing • If the row count in

airbyte_internal

has completely stopped growing for an extended period, that would indicate a genuine stall worth investigating further 👍 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 is there a better way to export the data from the hubspot itself ?

The knowledge sources do not contain enough information to recommend alternative HubSpot data export methods beyond what the Airbyte connector supports. What I can say based on the knowledge sources is that the

contacts_web_analytics

stream is inherently slow due to its per-contact partitioning design — there is no way around this within the current Airbyte HubSpot connector architecture. [manifest.yaml] What You Can Do Within Airbyte The most impactful thing you can control is reducing the date range: 1. Set a more recent

start_date

in your HubSpot source config — this directly reduces the number of 30-day windows per contact:193,381 contacts × 2 event types × fewer date windows = far fewer API calls 2. Disable

contacts_web_analytics

if you don't critically need it, and only enable it with a narrow date range when required. 3. Consider whether you need all 193,381 contacts — if your use case only requires web analytics for a subset of contacts, that's a HubSpot-side filtering problem outside Airbyte's scope. For alternative export methods directly from HubSpot (e.g., HubSpot's native export, their Reporting API, or third-party tools), I'd recommend consulting the HubSpot API documentation directly, as that falls outside what the Airbyte knowledge sources cover. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.