agent timed out waiting for fivetran sync to finish, sync stuck
Gives agents a playbook for Fivetran syncs that never finish: reading sync phases, bounded waits, and escalation. Use when an agent waits on a sync that stalls. Not for syncs that fail fast.
TL;DR
A sync that never finishes is stalled in one phase: extracting against a throttled source, loading against a busy warehouse, or retrying a failing step. The agent should read the sync history to find the phase, wait a bounded time for normal variance, then escalate with the phase named. An agent cannot fix a throttled source by waiting harder.
agent timed out waiting for fivetran sync to finish, sync stuckUse this when
- An agent waits on a Fivetran sync that stalls.
- The sync shows progress then stops advancing.
- The agent's timeout fires while the sync is incomplete.
Not for this skill when
- The sync failed with an error. Read the error.
- The sync is slow but progressing. That is a duration question.
Steps
- Read the sync history and identify the current phase and how long it has been there. Note the stuck phase. Verify: the stall point is named
- Compare against the connector's normal sync duration. Note whether this is variance or a real stall. Verify: normal versus stuck is decided
- Wait a bounded time for slow-but-moving syncs, checking phase progress between waits. Note the deadline. Verify: waiting is bounded
- For a truly stuck phase, check the source status and warehouse load for the underlying block. Note the blocker. Verify: the block is identified
- Escalate with the connector, phase, and stall duration. Note the escalation. Verify: a human gets an actionable report
Variant phrasings
fivetran sync stuck agent wait
The agent-shaped search.
fivetran sync phase stalled
The phase-shaped phrasing.
Compatibility: Fivetran dashboard and API for sync history. Phase names are consistent across connectors.
Why it happens
Fivetran syncs are multi-phase and each phase depends on a different external system, so a stall is always a story about one of those systems: the source throttling extraction, the warehouse queuing the load, a schema change pausing everything. The sync history shows the phases, which means the agent can name the stuck phase instead of reporting a vague stuck sync. Bounded waiting respects that some stalls resolve themselves (a source recovers) while others never do (a hard throttle).
Edge cases / pitfalls
- Cancelling and retriggering a stuck sync can restart a long extraction from scratch. Prefer waiting out transient stalls.
- An agent that escalates every slow sync trains humans to ignore it. Escalate on stuck phases, tolerate slow ones.
- Syncs paused by schema changes look stuck but are waiting deliberately. Check for pending schema approvals.
- Multiple agents waiting on the same sync should coordinate, not each escalate separately.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_aRjrXvrZndPYeJQuugXESA