Auto-Retry & Recovery
Syncs depend on networks, vendor APIs, databases, and third-party services—any of which can slow down or drop a request without indicating a real problem with your configuration. Connect treats many of those cases as transient: it detects stalled or unresponsive work, automatically retries so stressed systems get room to recover, and stops retrying when the issue looks persistent so you are not left watching a silent loop.
How it works
During a sync run, Connect watches for signs that the source or destination has stopped making progress within expected time windows. When that happens, it treats the failure as transient and restarts the affected work so retries do not pile onto an already overloaded API or database.
Retries trade a little latency for stability: brief outages and slow responses often clear on their own; hammering the same endpoint rarely helps.
Why transient failures happen
API sources
Some APIs respond asynchronously or hold requests open while work completes elsewhere. Rate limits can also delay responses longer than a single call usually takes. Either situation can make a job look hung even though the upstream system is still healthy.
Database sources
Large tables, concurrent queries, and resource contention can stretch read times. Where the source connector supports incremental reads, an unindexed cursor column on a large table forces the filter into a full table scan, which can push a routine query past its timeout—indexing the cursor column usually resolves this when you control the schema. Note that incremental reads are not available for every source connector; check the connector's reference for what it supports.
Destinations
High write volume relative to available capacity slows acknowledgements. That usually points to throughput or batching limits on the destination side rather than a miswired connection.
What you see
Most of the time, automatic retries resolve the issue without any action on your part. The run may take longer than usual, but it completes once the upstream system catches up.
When retries are exhausted or the failure is clearly not transient—bad credentials, a sustained vendor outage, a permission error—Connect surfaces the failure so you can investigate. Retries are for noise; persistent errors are for humans.
If failures keep coming back
- Confirm the source is up — Check the vendor status page or database health before chasing Connect-specific causes.
- Validate the connection — Credentials, scopes, and firewall rules are the fastest wins when every run fails the same way.
- Review incremental database reads — Ensure the cursor column used for incremental syncs is indexed on large tables.
- Check destination capacity — Especially during large backfills or full refreshes, the destination may need more headroom for writes.
- Watch for rate limits — Tight schedules plus heavy endpoints can produce sustained throttling; spacing or volume changes often help.
If you have done the obvious checks and the job still will not stay green, contact Propexo support with the failing connection and time window so the team can dig in with you.