Troubleshooting sync and data issues

What integration statuses mean, how to reauthorise each provider, and how to fix unattributed work, missing AI spend and stale data.

Updated 17 July 2026

Most "where's my data?" questions come down to one of three things: an integration that isn't syncing, identities that aren't linked, or a sync that simply hasn't run yet. This page works through each.

Find your symptom:

Integration statuses

The Integrations page shows a status on every connection:

StatusMeaningWhat to do
ConnectedSyncing normallyNothing
Never syncedConnected, first sync not finishedWait a few minutes; check selections are saved
Needs reauthProvider access expired or was revokedReconnect (below)
ErrorThe last sync failedSee "Sync errors"
PausedDisconnected, or plan inactiveReconnect, or check billing

Each card also shows when the integration last synced. Transient failures are retried automatically with increasing backoff and aren't surfaced as failures unless they persist for a few hours, so a brief provider outage usually resolves itself before you notice.

Reauthorising a provider

When a token expires or is revoked, EngLedger stops syncing and marks the integration Needs reauth. It won't retry silently with dead credentials. Reauthorising is the same as connecting the first time, and your repository or project selections are preserved:

  • Jira: run Connect again from the Integrations page and approve on the Atlassian consent screen (details). Jira access is refreshed automatically day-to-day; reauth is needed when the grant itself has expired or been revoked.
  • Bitbucket: run Connect again and approve (details).
  • GitHub: the GitHub App doesn't use expiring user tokens, so reauth is rare. If the app was uninstalled on the GitHub side, the integration pauses; reinstall via Connect (details).

Recovery also runs from EngLedger's side: integrations whose credentials work again are reactivated automatically within about 15 minutes.

Sync errors

A red Error status means the last sync failed after retries. The most common causes:

  • Rate limiting. EngLedger throttles before provider ceilings (GitHub 5,000 requests/hour; Bitbucket 1,000) and defers the remainder of the sync rather than failing, but a very large backfill can take several windows to finish. This shows as slow, not broken.
  • Permissions changed at the provider. A repository the selection still references was made inaccessible. Reopen the selection screen and re-save.
  • Provider outage. Waits it out; recovery reactivates the integration when calls succeed again.

If an integration stays in error, disconnect and reconnect it. Selections are kept.

Work is missing or attributed to nobody

If hours or cost look low for a person (or work shows hours with no cost) it's almost always identity mapping:

  1. Open the Identities page and check the Unlinked tab. Link any accounts belonging to your people.
  2. Commits from unlinked authors generate no effort at all; linking the identity processes the past year of their commits retrospectively.
  3. Worklogs from unlinked identities keep their hours but carry no person and no cost, and won't appear in per-person views.

People and identities explains the model. Also check the person has an hourly rate. Hours without a rate produce no cost by design.

Commits aren't linking to tickets

Links come from ticket references: a Jira key (ENG-123) or issue number (#42) in the commit message, branch name or PR title. No reference, no link, and unlinked commits fall back to default classification. The fix is a team habit, not a setting; branch-per-issue naming gets you most of the way. See the scenario guides for how teams make this stick.

Data seems stale

Scheduled syncs run every 30 minutes by default, so a just-moved ticket can lag by up to that. GitHub push and pull request events arrive in real time via webhooks; Jira and Bitbucket changes wait for the next scheduled sync. If the last-synced time on the Integrations page is hours old with an active status, check whether your plan is active. Sync pauses when it isn't.

AI spend isn't appearing

If the AI reports are empty, work down the pipeline:

  1. Metering enabled? An admin turns it on under Settings → AI Governance. Until then, nothing is metered (setup guide).
  2. Is the person connected? Requests are only metered when a tool routes through the person's personal access URL. Check the AI tab on their profile. It shows their access URL and can resend the setup instructions. The usual culprits: the base-URL change was made but the tool wasn't restarted, or one of several tools was connected and the others weren't.
  3. Is anything flowing? Usage appears within minutes of a connected person's first request. The API Health report shows per-model request volume, error rates and latency. If it's moving, metering works and the problem is elsewhere.
  4. Access URL rotated? Rotating a person's access URL invalidates the old one immediately; tools still pointing at it stop being metered (requests fail rather than silently bypassing). Update the tool with the new URL.

AI sessions aren't attributing to tickets

Attribution needs evidence. A session links to a ticket through an explicit ticket reference, nearby code activity (a commit, merged PR or branch by the same person that resolves to exactly one ticket), or worklog overlap, in that order, and ambiguous signals abstain rather than guess. If sessions show no ticket:

  • Check ticket keys appear in branch names and commit messages. The same habit that links commits to tickets drives AI attribution.
  • Check the code host and issue tracker are syncing (statuses above): attribution reads commits, PRs and worklogs from your integrations, so a stalled sync stalls attribution with it.
  • Give it a day. Links re-resolve as commits, PRs and worklogs arrive, so a session's attribution often improves after the surrounding evidence syncs.

AI spend shows as unattributed

Unattributed spend means the request couldn't be resolved to a person: almost always an identity gap, the AI equivalent of work attributed to nobody. Spend with a known person but no ticket shows as unticketed instead, which is an attribution-evidence problem (above), not an identity one. Neither bucket is hidden or folded into totals. See how attribution works for what each bucket means and what an acceptable remainder looks like.

Still stuck?

Start from getting started to re-check each setup step, or contact us via the site.