When your data refreshes

Every source syncs on a schedule with no action from you. Manual controls exist for the moment you don't want to wait — right after fixing a broken connection, or right before a demo.

deckgauge · Board · Sources
Jira · PLAT — last synced 4m ago
GitHub · ada-systems/checkouttoken expired, skipped

Sync status, with one expired source skipped and flagged.

Scheduled sync

The worker runs a sync pass on startup, then repeats automatically — board-level connectors on roughly a 15-minute cycle; GitHub repos additionally sit on a hot/warm/cold tier (1h / 6h / 24h) based on how recently they were pushed to, so a quiet repo isn't polled as often as a busy one. Nothing here needs configuring — it's the default for every connected source.

Manual sync

  • Sync Now on a board — triggers that board's sources immediately. Before enqueueing, Deckgauge checks each source's health and skips any with an expired token rather than letting the whole sync fail; the button shows which sources were skipped and offers a one-click path to fix them.
  • Sync All Now / per-provider buttons on the intelligence sync panel — pulls the latest PRs, commits, status transitions, and worklogs straight into ClickHouse for a chosen provider (or all of them) without waiting for the schedule.

Board sync polls for completion for up to 30 seconds and refreshes the board's rows the moment it lands — you don't need to reload the page to see freshly synced items.

Watermarks and backfill

The first time a source is added, its historical backfill window is estimated up front (requests and rough minutes) so a large repo or project doesn't silently take hours before you know it's still working. After that, each project-sync row stamps its own lastSyncedAt the moment a run finishes, which is what the sync-status UI and health checks read to decide whether a source looks current.

Retired projects

Timesheet hours are inferred from status transitions, not filled in by hand. If you stop syncing a Jira project while its issues are still sitting "in progress," those items keep contributing hours to the timesheet forever — nothing tells the engine the work actually stopped. Retired projects exists to fix that: give a project key a cutoff date, and every in-progress span for that project is clipped to the cutoff. Hours logged before the cutoff are untouched; nothing after it counts.

Retiring is Jira-specific, and reversibleRetired projects are tracked by uppercase Jira project key with a cutoff date and an optional note. Removing a project from the retired list restores its hours exactly as they were — retiring is a filter on read, not a destructive rewrite of synced data.

If it looks wrong

SymptomCauseFix
Sync Now says a source was skippedThat source's token is expiredFollow the fix link — see When a connection breaks
A decommissioned project keeps accruing timesheet hoursIt was never marked retiredAdd it to Retired projects with the date it actually stopped
Dashboard numbers don't reflect a sync you recently ranThe board's rows haven't refetched yetWait for the in-progress poll to finish, or reload the board

Related

Last updated