How a widget gets its number

Most tiles on a dashboard view are a ClickHouse query, not a live API call — the board-state widgets (status distribution, items by owner, and similar) are the exception, reading the board's own Postgres data instead. When a ClickHouse-backed widget looks wrong, the fastest fix is to find which stage of the pipeline below is actually empty — not to stare at the chart.

The stages a number passes through, and the stage where this one stalled.

The path from a provider to a tile

A synced issue lives in Postgres too, as the board row you see in the grid — but the PR, commit, and review facts that feed ClickHouse-powered widgets don't have a Postgres copy at all; for those, Postgres only holds sync configuration (which repos and projects are connected, whether code intelligence is switched on for them, and a per-source lastSyncedAt pointer). Those facts go straight from the provider's API into ClickHouse:

1. Provider sync — a worker job calls the Jira/GitHub/GitLab/ADO API for the projects and repos you connected on the board's Sources tab.
2. Intel builder — the sync handler (e.g. the Jira changelog walker, or the GitHub pull-request/commit fetcher) transforms the provider's response into rows and inserts them directly into ClickHouse tables like jira_issues, jira_transitions, github_pull_requests, github_commits, gitlab_merge_requests, and ado_pull_requests.
3. Widget query — when a widget renders, its builder (one per widget type) turns the widget's config and this board's connected sources into a parameterized ClickHouse query.
4. Dashboard — the board batches every widget's query into one request and renders whatever comes back, including an explicit empty-state when nothing does.

Watermarks and backfill

The first sync after you connect a source is a backfill — it walks the provider's full history for that project or repo, page by page, before handing off to the regular incremental sync. Each page is inserted into ClickHouse as it arrives, and the sync only advances its watermark — the per-source "synced up to here" pointer — after that page is durably written. If a sync is interrupted mid-backfill, nothing is lost or double-counted: ClickHouse's tables dedup rows by id on merge, and the next run resumes from the last confirmed watermark instead of the very start.

Practically: a source that finished connecting five minutes ago may still be backfilling. A widget reading zero (or suspiciously few rows) right after connecting a source very often means backfill is still running, not a configuration problem.

Why Jira's "Done" is a name match, not a category match

Jira's REST API attaches a status category (To Do / In Progress / Done) to an issue's current status, but its changelog — the history of every past transition — does not carry a category per historical transition. Deckgauge's Jira sync writes that gap out explicitly: every row in jira_transitions gets from_category and to_category set to 'Unknown', always.

So the builders that need a "when was this actually finished" date — Throughput & Cycle Time, Completion Trend, Delivery Trend — cannot use category at all. Instead they normalize to_status (lower-cased, punctuation collapsed) and match it against a fixed list: done, closed, resolved. If your Jira workflow's terminal state is named anything else — "Released", "Shipped", a translated name — none of your transitions will ever match, and every completion-based widget will undercount or read zero even though tickets are visibly moving through your board.

If a widget reads zero

Related

• Filters & date ranges — how the period picker and per-widget config narrow a query.
• Status mapping — maps a source status onto one of your board's own statuses; a separate mechanism from the Done-name list above, which has no per-board override.
• Sync scheduling — when backfill and incremental syncs run.
• Widget reference — every widget's own "if it looks wrong" table.

Last updated 17 August 2026