Skip to main content

Sync Cycle

Every sync cycle:
  1. Fetch new/updated jobs since the last successful sync
  2. Apply filters (source, location, remote status, date range)
  3. Run the attached transformation pipeline (if any) — jobs dropped by Filter nodes or failed transforms are counted in the push log and skipped
  4. Batch upsert into your destination (up to 10,000 per batch)
  5. Remove expired jobs that have left the feed since the last sync
  6. Update cursor for the next cycle

Configuration


Initial Sync (Full Backfill)

When you first activate a feed — or switch to a different destination — a full backfill is performed. All jobs matching your filters are pushed to the destination. This may take several minutes depending on the volume of matching jobs. After the initial sync completes, all subsequent syncs are incremental: only new and updated records are pushed.

Full Resync vs Force Resync

Both actions scan every job matching the saved feed filters, but they handle the existing destination differently: Force resync is available on every saved destination, including inactive ones. Running it does not change which feed is active.
Force resync is destructive. Custom columns, mappings, settings, indexes, triggers, grants, and policies attached to the configured table or index are not preserved. Data is unavailable while the rebuild runs and can remain empty or partial if the sync fails.
The destination cards show the current phase, scanned and estimated rows, progress, and write/filter/delete counts. Select a card’s activity view for attempt-level diagnostics.

Deduplication

Jobs are deduplicated by their unique ID. If a job already exists in your destination, it is updated in place (upsert semantics). This means:
  • No duplicate records are created
  • Re-syncs are safe and idempotent
  • Updated job fields (title, description, salary, etc.) are reflected automatically

Expired Jobs

After the first sync, each cycle also removes jobs that have expired since the previous sync — deletions are matched by job ID, so they work even when a transformation pipeline has reshaped the documents. If you consume job data outside the outbound feed, the Expired Jobs API endpoint returns recently expired job IDs so you can prune your own stores.

Retry Schedule

If a sync fails, Jobo automatically retries with exponential backoff:

Failure Handling

If a sync fails after all 4 retries:
  • The feed is paused automatically
  • You’ll receive a notification in the dashboard
  • The cursor is not advanced, so no data is lost
  • Fix the issue and re-enable the feed to resume from where it left off
Sync status and history are available in the dashboard under Data → Outbound Feed.