A sync is stuck, or never finishes
A first load on a large database legitimately runs for hours, so “still syncing” is usually a slow job rather than a stuck one. This article shows you how to tell the two apart in about a minute, what a rate limit in your own tool looks like from here, and what to copy out when you need to raise a case. If a run stops with a message rather than never finishing, read A connection stopped working or asks me to reconnect instead.
Before you start
You need the tool connected and one sync started. Everything below is readable on screen; nothing needs support.
Tip
Check whether the count is moving before anything else. A manual run reports after every chunk, so a number that climbs every forty seconds or so is working, however long it has left.
How a sync actually runs
Knowing the shape of a run makes most of the confusing cases obvious.
- A run is cut into chunks. Each chunk does about forty seconds of work on the server, saves where it got to, and reports back.
- A manual run is driven by your browser. The tab asks for the next chunk each time one comes back, which is why the status line says "keep this tab open".
- Every chunk writes by upsert, so repeating one changes nothing. An interrupted run costs you nothing.
- One run per tool per workspace at a time. It holds a lease for two minutes, renewed while it works.
- A manual run stops after 300 chunks. On a very large first load that is a stopping point rather than a failure: press Sync again and it carries on.
Note
The first sync of a brand-new workspace has one extra step. Each workspace gets its own database, created on first use, which takes about twenty seconds. The status line says "Creating this workspace’s database — it takes under a minute the first time…" and MarqIQ waits and retries four times on its own.
What a first load legitimately takes
Before the first chunk lands, the estimate on screen assumes 85 records a second; from then on it is refined from the rate your run is actually achieving. Use the estimate on the page rather than a figure from this article, because it is measured on your data.
- A manual run and the scheduled run share the same engine, so a load you start and leave is finished by the schedule.
- The scheduled run fires on the hour and, while a first load is still in motion, again at quarter past, half past and quarter to — four chunks an hour instead of one.
- Marketo is the slowest first load by some distance. It has no "list all people" call, so the first sync walks the person-id space in batches of 300 until roughly ten thousand ids in a row come back empty. Each chunk scans about 10,500 ids, so how long it takes depends on how high your person ids run rather than on how many people you have.
- Adobe Journey Optimizer spends its first minutes inside Experience Platform rather than in MarqIQ. The status line says so: "Experience Platform is evaluating the audience — usually a few minutes…", then "Experience Platform is exporting the audience’s profiles…", then "Reading the exported profiles…". A count of zero during those stages is expected.
Reading the last run
Open the Connected Data Sources card on Attribution & Journeys, or the tool’s card on Data sources. Both need Pro or above. A run records more than one number, and the colours mean something exact.
| What you see | What it means |
|---|---|
| A line in red | A failure, in your tool’s own words. This line is only ever a failure. |
| A line in grey | Narration, not a failure: removals-lane results, coverage warnings, "more to sync". It is shown only when there is no red line. |
| Covered through Nh ago, in amber | How far behind the coverage is. It appears only once that passes 24 hours, and it is not a failure. |
| Last sync: a date | When the last run finished. That is not the same as how far the data is covered. |
| Not synced | The tool is connected and holds no records yet. |
A run that set records aside is recorded as partial rather than successful, even when nothing threw.
The causes, most common first
"Another sync is already running for this workspace — it will finish on its own"
Why: The scheduled run holds the lease for this tool. Your click arrived while it was working, so MarqIQ stopped quietly rather than walking the same records twice.
Fix: Nothing to do. The message is shown in green on purpose — your data is being refreshed right now. Wait a couple of minutes and press Sync again if you want to watch it.
The count climbed and then stopped, and the tab is still open
Why: A chunk came back with an error after MarqIQ had already retried it. The message names the cause and the words "progress is saved" follow it.
Fix: Read the message, fix the cause in your tool, and click Sync again. The run resumes from the saved position rather than starting over.
The count stopped and you had closed the tab
Why: A manual run is driven by your browser. Closing the tab ends the loop mid-run; the server chunk it was on finishes and nothing after it starts.
Fix: Open the tool and click Sync. The scheduled run would have picked it up as well, within the hour.
The card says the run is still going, hours after anything moved
Why: A run whose server function was killed leaves its log row saying "running", because a killed function runs nothing on its way out. MarqIQ sweeps those: a run with no completion recorded after thirty minutes is marked as an error reading "Sync timed out (no completion recorded)."
Fix: Wait for the sweep, or press Sync now — the lease it held expires on its own within two minutes, so a new run can take over and resume from the saved position.
Progress crawls in bursts with long pauses
Why: Your own tool is throttling MarqIQ. A 429 or a 5xx is retried with a growing wait, honouring the Retry-After your tool sends, up to three retries and at most ten seconds a wait.
Fix: Let it run. The pauses are MarqIQ waiting the time your tool asked for, and a chunk that runs out of budget mid-wait saves its position and resumes on the next one.
Marketo stops and says the daily quota is spent
Why: Marketo’s daily API quota is shared with everything else that calls your instance, and a full first load is thousands of calls.
Fix: Wait for the quota to reset. The field screens say so in plain words and tell you to try tomorrow; elsewhere you get Marketo’s own message as it wrote it. Nothing is lost — the run resumes from where the quota ran out.
Every screen is slow to respond the first time you open it after a quiet spell
Why: Your workspace’s database suspends after a few idle minutes, and the first query pays the wake-up — half a second to a little over a second. MarqIQ wakes it at sign-in and when you show intent to open a section that reads it.
Fix: Nothing to fix. It affects the first read only, and a sync in progress keeps the database awake.
A tool has not refreshed for most of a day and nothing is wrong
Why: Nobody has signed in to this workspace for seven days, so it is refreshed about every six hours instead of hourly. That is deliberate: every sync wakes the workspace’s database.
Fix: Sign in. The workspace counts as active again and the next hourly run refreshes it. Or press Sync and have it now — a manual run is never slowed by this.
HubSpot contacts refresh and HubSpot deals and companies do not
Why: They are two engines on one connection. The Sync button runs the contacts engine; companies and deals are pulled by the scheduled run.
Fix: Wait for the scheduled run. Its progress shows under the Data sources entry for HubSpot, and the Deals and Companies sub-tabs of Field Intelligence say in as many words when nothing is synced for them yet.
Telling a partial run from a failed one
These are three different outcomes and MarqIQ records them separately rather than calling everything that is not perfect a failure.
| Outcome | What happened | What to do |
|---|---|---|
| Success | The walk finished and wrote everything it fetched. | Nothing. |
| Partial | Records were fetched and some could not be written. They are kept with their reason, not lost. | Read Some records did not come through. |
| Error | The run stopped. The saved position is kept, so the next run resumes. | Read the red line, fix the cause, press Sync. |
Only a run that finished without an error is allowed to move the coverage mark forward. A run that stopped keeps the previous one, so coverage never claims more than it covered.
What to copy out when you raise a case
Send these and the run can be read without guessing. All of them are on the tool’s card under Data sources, or in the Connected Data Sources card on Attribution & Journeys.
- The tool, and whether the run was one you started or a scheduled one.
- The red line exactly as written, including your tool’s own wording.
- The grey notes line, which carries the removals-lane result and any coverage warning.
- The Covered through Nh ago figure, if it is showing.
- The record count on the card, and what your own tool reports for the same object.
Note
Each run also records how many records it fetched against how many it wrote. A gap between those two is the most useful signal there is — records arrived and did not land — and no screen shows the pair today, so ask support to read it from the run.
If it did not work
Pressing Sync does nothing at all and no line appears
Why: A run is already in flight in another tab, or the button is disabled while one is running.
Fix: Close the other tab, reload this one, and press Sync again.
The estimate on screen keeps rising as the run goes
Why: The estimate is refined from the rate your run is achieving. A run slowed by your tool’s throttling reports a longer estimate than it started with.
Fix: Nothing to fix. The figure is honest about the rate it is seeing rather than holding to its first guess.
A run ends reporting fewer records than your tool holds
Why: A manual run stops after 300 chunks, and a very large first load needs more than that.
Fix: Press Sync again to carry on, or leave it — the scheduled run drains a load that is in motion four times an hour until it finishes.
The very first sync after connecting says the workspace’s database is not ready
Why: The database is created on first use and takes about twenty seconds. MarqIQ waits and retries four times before it gives up.
Fix: Wait a few minutes and press Sync.
Next steps
Related articles
Was this article helpful?