fabriclink

Backfill & history

After provisioning, Fabric Link exports the current state of in-scope issues and optionally crawls each issue’s complete changelog.

Initial backfill

When sync starts, the app pages through all in-scope issues and writes rows to mirrored tables. Progress appears on the Health tab.

Backfills are paced deliberately — roughly one page of issues per five-minute cycle — to stay inside Jira API quotas without affecting site performance. Large sites may take hours or days; the Health tab shows live progress and estimated completion.

Full changelog history

Enable Include full history to crawl each issue’s complete changelog. The jira_changelog table then covers field changes from before the app was installed — not just from install day forward.

Turning history on later automatically queues the historical crawl for projects that already finished their initial backfill.

-- Example: field changes for a single issue key
SELECT field_name, from_value, to_value, changed_at
FROM jira_changelog
WHERE issue_key = 'FL-204'
ORDER BY changed_at;

Live sync after backfill

Once backfill completes:

  • Webhooks stream creates, updates, and deletes
  • A five-minute reconciliation sweep catches anything a webhook missed
  • Hourly reference refreshes keep lookup tables current

Rate limits

| Constraint | Behavior | | --- | --- | | Jira REST rate limits | Backfill paces requests automatically | | Fabric write throughput | Batched change files; dead-letter on failure | | Large projects | Longer backfill; monitor Health tab |

Next steps