## TL;DR
A sync that drags for hours then fails is usually fighting the source: API throttling, a huge backlog, or a source that keeps resetting the connection. Check the connector's sync history for where the time went and whether the source logged throttling. Fix the source-side constraint or narrow the sync scope; the Fivetran side is usually just the messenger.

```text
fivetran connector sync delayed for hours then failed
```

## Use this when
- A connector sync runs for hours then fails.
- The delay is new; the same connector used to finish quickly.
- Sync history shows progress stalling at the same phase each time.

## Not for this skill when
- The sync fails immediately. That is a setup or auth problem.
- Syncs are slow but complete. That is performance tuning.

## Steps
1. Open the connector's sync history and note where the hours went: extraction, loading, or waiting. Note the slow phase. Verify: the stall point is identified
2. Check the source for throttling, maintenance windows, or degraded status during the window. Note any source-side event. Verify: source problems are found
3. Look at data volume: a backlog after a pause or a new large table explains slowness honestly. Note the volume. Verify: volume is quantified
4. Narrow the scope if possible: exclude unneeded tables or switch huge tables to a less frequent sync. Note the reduced scope. Verify: the workload fits the source
5. Let the next sync run and confirm it completes in the normal window. Note the duration is back to baseline. Verify: recovery is verified

## Variant phrasings
### fivetran sync taking too long
The performance phrasing.
### fivetran sync stuck then failed
The symptom search.

Compatibility: All Fivetran connectors. Sync history and phase breakdown are available in the dashboard for every connector.

## Why it happens
Fivetran syncs are bounded by the source API's rate limits and reliability, not by Fivetran's capacity. When a source throttles, the sync slows to the throttle pace; when the source drops connections, Fivetran retries and the clock keeps running. Hours of delay followed by failure usually means the retries finally exhausted against a source that never recovered. The dashboard's phase timing tells you whether the hours were spent extracting (source problem) or loading (warehouse problem).

## Edge cases / pitfalls
- Initial syncs of large tables legitimately take hours. Compare against the connector's own history, not against incremental syncs.
- A source schema change mid-sync can force a re-extraction that looks like a stall. Check the schema change log.
- Pausing and resuming a connector creates a backlog that the next sync must chew through. Expect one slow sync after any pause.
- Some sources rate-limit harder during their own peak hours. Schedule heavy syncs off-peak where the connector allows it.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GCC87TeU1ScV9YA19ms2tw