Troubleshooting GitHub Data Quality

This guide helps you find and fix the most common GitHub data gaps in Span, such as a person you know is shipping code showing - (no data) in PRs merged / week, or PRs that appear while PR Lifecycle and commit-based metrics stay blank.

Why it matters

Most gaps come from a small mismatch you can fix yourself, in Span or in your GitHub organization. Fixing the cause, instead of the symptom, keeps a person's metrics right from then on.

How it works

Three things must line up before a person's GitHub activity shows in their metrics:

1. The repository is connected and synced. Span only sees repositories your GitHub App installation can access, after Span has synced them. Activity in a repository Span can't see is invisible, however much the person contributed.

2. The pull request matches a person through their GitHub username. Every PR has an author identified by a GitHub username (login). Span maps that username to a person in your organization. If the username isn't on anyone's Span profile, or is on the wrong one, the PR can't count for them.

3. The commits match a person through their Git author email. Commit-level signals, such as first commit time and coding time, drive most PR Lifecycle stages. GitHub links a commit to an account when the commit's author email is added and verified on that GitHub account. If it isn't, the commits stay unattributed even when the PR itself is attributed.

Key takeaway: "PRs merged" depends mostly on (1) repository sync and (2) the GitHub username. "PR Lifecycle and commits" also depends on (3) the Git author email. That is why a person can have a healthy "PRs merged" count but blank lifecycle metrics.

How to fix it

60-second checklist. These questions resolve most cases:

• Is the date range wide enough? Metrics only count activity inside the selected window. Widen it to confirm whether data exists at all.

• Does the person have a GitHub username in Span, and is it the right one?

• Did the person actually merge a PR in the period? Confirm in GitHub.

• Is the repository connected and synced?

• Is the person active and marked as a Contributor? Inactive people and Observers can drop out of some views.

• Has a sync run since the activity? Span syncs GitHub about every 2 hours, so very recent activity may not show yet.

Fix 1: "PRs merged / week" shows -

A - means Span has no PRs attributed to this person in the selected range. Work through these steps in order.

1. Check the person has a GitHub username. Go to Settings → People Management, find the person, and open their profile. The GitHub Usernames field appears only when the person is set to Contributor. If it is empty, add the username. Span can't match PRs without it.

2. Check the username is correct. In GitHub, open a PR you know this person merged and note the author handle (the @username next to "opened this pull request"). It must match the username in Span, with no leading @ and no extra spaces. GitHub usernames are not case-sensitive.

3. Confirm the person merged a PR in the period. In GitHub, search the organization with is:pr is:merged author:THEIR_GITHUB_USERNAME. Confirm at least one PR was merged (not just opened or closed) and note its merge date. If nothing merged in your window, - is correct.

4. Widen the date range in Span so it covers the merge dates you found, for example the last 90 days.

5. Confirm the repository is synced. Go to Catalog → Repositories and search for the repository. If the list is long, export it to CSV and search the file. If the repository isn't listed, see Fix 3. If it was just added, wait for the next sync.

6. Re-check after the next sync. Username fixes and new repositories take effect after the next sync, about 2 hours.

Fix 2: PRs show up, but PR Lifecycle or commit metrics are blank

The most common cause is a Git author email on the person's commits that isn't on their GitHub account. Typical triggers:

• A personal email set locally instead of the work email.

• A default email such as you@example.com or the machine hostname.

• A new laptop or fresh Git install where user.email was never set.

• An email that is set but not added and verified on the GitHub account.

1. Confirm the symptom: on the person's page, PRs merged has values but PR Lifecycle or commit metrics are missing for the same period.

2. Check the commit author email. Ask the engineer to run git config user.email. For a specific commit, run git show -s --format='%an <%ae>' <commit-sha>. %ae is the author email that GitHub uses to link the commit to an account.

3. Compare against their GitHub emails. Have the engineer open GitHub → Settings → Emails. If the commit email isn't listed and verified there, that is the cause. If they use GitHub's "Keep my email address private" option, commits may use a …@users.noreply.github.com address. That works as long as it is the address GitHub gives their account.

4. Fix the local Git email. Set it to an email that is verified on their GitHub account:

   git config --global user.email "work-email@yourcompany.com"
   git config --global user.name "Their Name"

   Or, for one repository only (useful for people who switch between personal and work accounts), run git config user.email "work-email@yourcompany.com" inside that repository. Then run git config user.email again to confirm it prints the corrected address.

5. Or add the email on GitHub. If the commit email is a real work address, adding and verifying it under GitHub → Settings → Emails also works for new commits.

Fix 3: data is missing for a whole repository or team

1. Check the connection status. In Settings → Integrations, open GitHub. If a connection shows Reconnect required, choose Reconnect. If it shows Disabled, contact support.

2. Check repository access. In GitHub, go to your organization settings → GitHub Apps → Span, and confirm the installation includes the repository. Organization owners can change the list.

3. Check ignore rules. In Settings → Metrics, make sure Ignore Repositories and Ignore Branches don't match the repository or its branches. These rules drop matching data from metrics.

4. Check the right GitHub organization is connected. Each GitHub organization is its own connection. Add a missing one with Connect another.

5. Wait for the next sync. A newly granted repository needs an initial sync before data appears.

Things to know

• History doesn't change when you fix a local email. Past commits keep the email they were written with. New commits are attributed correctly from the fix on. Avoid rewriting shared Git history just to backfill metrics.

• One person, several GitHub accounts. Some engineers use more than one handle. Add every username to the same person's GitHub Usernames field. If only one is mapped, the other account's PRs won't count.

• A username can belong to only one person. If you see "GitHub account already assigned to another person", remove the username from the other profile first, then add it to the right one.

• New contributors show in Data Quality. People Management shows a Data Quality Issues badge when GitHub contributors have no matching person. For each one, choose Add person to create a new person, or Ignore. To attach the login to someone who already exists, add it to that person's GitHub Usernames instead.

• Bots and automation accounts. Bots such as dependabot, release bots, and CI accounts open and merge PRs but aren't people. Don't map them to a person. Add them to Ignore Git Usernames in Settings → Metrics so they drop out of metrics.

• External contributors and forks. PRs from outside collaborators or forks don't count toward anyone unless the author's username is mapped to a person in Span.

• Squash merges. Span reads each pull request's own commits, which keep their original authors after a squash merge. The emails on those original commits, not the squashed commit, must be on the author's GitHub account (see Fix 2).

• Worked example. An engineer merges 6 PRs in March. Their GitHub username is in Span, so PRs merged / week shows a value. Their laptop commits with dev@laptop.local, which isn't on their GitHub account, so none of the commits link to them and Coding time is blank. They set user.email to their verified work email on April 2. PRs they open after the next sync show full lifecycle data. The March PRs keep blank coding time.

What to send support if you're still stuck

• The person's name and a link to their page in Span.

• The metric affected (for example PRs merged / week or PR Lifecycle) and the date range you're viewing.

• The GitHub username stored in Span for that person.

• A link to a merged GitHub PR you expect to see, with its merge date.

• For commit issues: the output of git config user.email and git show -s --format='%an <%ae>' <commit-sha> for an affected commit, plus the emails verified on the person's GitHub account.

• The repository name, and whether it appears in Catalog → Repositories.

• Roughly when the activity happened and when you first noticed the gap.

Related articles

Integrating GitHub with Span

People Data & Roster Management

What determines contributor status in Span user profiles?

Metrics Settings

Need help?

Contact your Span account team or reach out to support@span.app.