Data coverage
Where workspace admins check whether ingest finished, is still running, or failed.
Data coverage is the place to see whether connected pipelines have finished ingesting, are still backfilling, or failed. It is not Message Center, and it is not an Insights chart.
Who sees it
Workspace admins (and platform admins) get Data coverage in the workspace settings menu, next to Integrations.
Open the workspace menu in the top bar, then {workspace} settings → Data coverage (/workspace/data-coverage).
Members do not get that menu item this release. A direct link to the same page still loads if you already have workspace access.
What the page is for
After a connect or ingest cycle, use Data coverage to answer:
- Did this pipeline finish, is it still running, or did it fail?
- What failed or is missing?
- What should I do next?
You should not need worker logs for that.
Integrations also links here when a connected pipeline is failed, stale, or missing days in its window.
If no pipelines exist yet, the page says No ingest pipelines yet and points you to Integrations.
First fill and rate limits
The first fill for a pipeline follows that provider’s rate limits. While status is Backfilling, in progress, or not started, a long wait is expected pacing, not a 24-hour service promise. There is no countdown on the card.
Status labels
Pipeline cards use these labels:
- Backfilling: ingest is still running. For Productivity (GitHub), when a historical week is being written, the card names that week, how many repositories are queued for it, and the share of repositories that already have a merged pull request on record. Other pipelines show a progress percent when the app has it.
- Backfill complete: the current queue or phase has drained. That is not the same as Source verified.
- Failed: ingest stopped with an error. The card shows a human-readable reason when one is available.
- Service degradation: regular sync is more than 24 hours behind after the initial fill. That is a service problem, not ordinary lag. Productivity shows it when the pipeline is complete and lag passes 24 hours. HR & people and Monitoring show it when the last sync succeeded and lag passes 24 hours. AI usage does not use this label; usage data is collected on a weekly schedule, and reports stay on demand. SDLC does not use this label in this release.
Stale and gap notes can appear after a pipeline has data. While a pipeline is still backfilling (or has not started), stale warnings are held back so you are not told the data is old while it is still filling in.
For AI usage, HR & people, and Monitoring, the card can show Next scheduled poll (with a relative time) when the next sync is still ahead, or Scheduled poll overdue when that time has already passed. Productivity and SDLC do not use that poll line. The page does not invent an ETA; a past poll time means overdue, not a countdown to finish. Monitoring expand details can also list issue, deployment, and event counts when the pipeline has them.
Productivity source check
On the Productivity GitHub card, Coverage is stored merged pull requests divided by the merged pull requests GitHub has in the 180-day window. The ratio sums the latest check of each repository. A repository that GitHub and the platform both report as 0 is covered. The bar stays hidden until at least one repository has a numeric check. While a week is still being written, that bar waits and the card shows the week being saved instead.
A separate line reports the latest source-check sample. While a week is still being written, that line waits: the repository list says a check against GitHub starts after those weeks are saved. Backfill complete only means the queue drained. It does not mean every week had a merged pull request. A week is a gap only when GitHub has merged pull requests for that week and the platform does not. A week with no merges on GitHub is not a gap, and it is not incomplete data. Source verified is that separate line, and it appears only when the check passes. AI usage, HR & people, Monitoring, and SDLC do not show this line.
The check runs about every 7 days on a sample of up to 10 repositories. Source verified uses the lowest repository in that sample. The Coverage bar uses every repository that has been checked, not only the latest sample. Both compare merged pull requests on the platform to GitHub merges over the last 180 days. The sample target is 90% or higher.
| Label | Meaning |
|---|---|
| Not verified yet | Backfill is not finished, or no source check has completed. This is not source verified. A last-sample percent can still appear when one exists. |
| Source verified | The latest sample is at or above 90% of GitHub merges over 180 days, and the check is under 7 days old. The percent is shown. |
| Below source target | The latest sample is under 90% of GitHub merges over 180 days. The percent is shown. |
| Not enough source data | The check ran, and no sampled repository had a GitHub merge count this check could use. No percent. |
| Source check overdue | The last check is 7 days old or older. A last percent is history only; this is not source verified. |
Retries stopped
When Productivity GitHub stops retrying a repository for a lasting reason (for example max retries exceeded, missing access, or a revoked installation), that repo row can show Retries stopped or a clearer label for the same class of problem. Benign skips such as empty or archived repos do not get that treatment. If any repo is in that stopped state, the productivity card also calls it out, including when the pipeline already shows repo failures.
What to do next
Connect or reconnect under Settings → Integrations. Then come back here to see whether that pipeline recovered.
HR & people and Monitoring document Sync now on Data coverage for those pipelines. Sync refreshes the configured window; it does not rebuild arbitrary historical days outside that window.
Workspace admins can Retry a failed Productivity GitHub repository from its row on this page when the pipeline is not already backfilling or in progress. Retry re-queues that repo only; it does not start a new full-history backfill. If the pipeline is locked or a backfill is already running, the page explains why and leaves the rest of the list usable. For rate limits or waiting states without a Retry control, reconnect GitHub, wait for backoff, or open Integrations.
Fill since last fetch
Workspace admins and platform admins can use Fill since last fetch on Data coverage. Members do not see the button.
It pulls from the last successful fetch through now. It does not restart full history, and there is no date picker.
- AI usage: one button per connected provider. That starts the existing incremental refresh (not a full rebuild). While that provider’s refresh is already in progress, the button stays hidden. If a refresh is already running, you get the usual busy message.
- Productivity GitHub: only when the pipeline is Backfill complete. It queues a catch-up from the last ingest through now without changing the completed phase.
- HR & people, Monitoring, and SDLC keep Sync now / rebuild controls; they do not get Fill since last fetch.
Prefer GitHub cutover (Bitbucket + GitHub)
When both the GitHub App and Bitbucket are connected, workspace admins and platform admins see Prefer GitHub since on the Productivity (GitHub) card. Members do not see this control.
Enter a UTC date and time, then Save. From that instant, the platform prefers GitHub for productivity attribution so transition-period merges are not double-counted. Bitbucket-only merges after that instant are not attributed. Clear removes the cutover.
See also Bitbucket.