How to Track GitHub Copilot Usage Across Your Engineering Team

Most engineering teams that buy GitHub Copilot licences find out three months later that 30% of their seats never left the onboarding email. The native dashboard says 28 active users out of 40. Nobody knows which 12 went dark, why, or whether there is a tooling issue or just a habit problem.

This guide explains what GitHub Copilot's built-in analytics actually tell you, where they stop, and what tracking infrastructure you need to get real adoption visibility across your team.

What does GitHub Copilot's native usage analytics show?

GitHub Copilot's native analytics show active user counts, aggregate suggestion acceptance rates, language and IDE breakdowns, and seat-level last-activity timestamps — enough to know the team is using it, not enough to know why usage is low for specific developers.

GitHub provides analytics at two levels:

GitHub.com dashboard (Copilot Business / Enterprise admins)

• Active users count (28-day rolling window)
• Suggestions accepted per day
• Acceptance rate (accepted / shown)
• Breakdown by programming language
• Breakdown by IDE / editor

Copilot REST API (programmatic access)

• GET /orgs/{org}/copilot/metrics — daily breakdowns of active users, total suggestions, and acceptance rates at the org level
• GET /orgs/{org}/members/{username}/copilot — per-seat data including last_activity_at, last_activity_editor, and plan_type
• Team-level aggregates via GET /orgs/{org}/teams/{team_slug}/copilot/usage

API access note. Per-seat usage data requires a GitHub token with manage_billing:copilot scope. Team-level usage requires read:org. Individual developers cannot call these endpoints on behalf of their org — admin credentials are required.

What does "active user" mean in GitHub Copilot's analytics?

GitHub counts a developer as an "active user" if they accepted at least one AI suggestion in the past 28 days. A developer who used Copilot for 20 minutes on a Saturday and then stopped appears as "active" for another 27 days. Active user counts overstate real adoption — teams that rely on this metric alone consistently underestimate their ghost seat problem.

What does GitHub Copilot usage analytics miss?

GitHub Copilot's native analytics miss four things engineering managers need: per-developer session depth, project-level attribution, trend data below 28 days, and cross-tool comparison when teams run both Copilot and Claude Code.

What you want to know	Copilot native analytics	What it actually takes
Which developers use Copilot daily vs. once a month	❌ Not available	Per-seat session-level logs
Which projects get the most AI assistance	❌ Not available	Repo-level session tagging
Which developer's seat went dark this week	Partial — last_activity_at but no alert	Automated seat monitoring with delta detection
Is Copilot improving PR cycle time?	❌ Not available	AI-assisted commit ratio mapped to lead time
Ghost seats (paid, never activated)	Partial — zero last_activity_at	Active seat monitoring from day 1 of provisioning
Claude Code usage alongside Copilot	❌ Not available	Unified analytics layer across tools
How acceptance rate is trending per developer	❌ Aggregate only	Per-developer time-series data

The gap between what the dashboard shows and what managers actually need is the reason teams discover ghost seats at renewal time rather than week two.

For a renewal checklist that works across AI coding tools, see how to find unused AI coding licenses before renewal.

How do you measure GitHub Copilot adoption rate across your team?

Measure GitHub Copilot adoption as a ratio of seats with meaningful weekly usage to total provisioned seats — not GitHub's 28-day active user count, which is too permissive to catch low-frequency users.

A practical adoption rate formula:

Adoption rate = seats with 5+ accepted suggestions in the past 7 days ÷ total provisioned seats

This weekly threshold captures developers who are building a consistent habit, not just touching the tool once a month to keep the metric green. In CloudByte AI data, teams that measure adoption this way typically see a 15–25% lower adoption rate than their GitHub dashboard reports — which is a more accurate signal and a better basis for coaching decisions.

What to do when adoption rate is below 50%

Below 50% meaningful weekly usage within 90 days of rollout, there are three root causes to investigate in order:

1. Tooling failure. IDE extension not installed, corporate network blocking the Copilot endpoint, or auth token expired. Run a setup health check across all developer machines — this is the fastest problem to fix and affects more teams than expected.
2. Workflow mismatch. Developers tried Copilot on tasks where it adds little value (reading legacy code, debugging rare edge cases) and concluded it was not useful. The fix is use-case coaching: position Copilot for greenfield drafting and test generation, where gains are most consistent.
3. No reinforcement. Nobody is checking usage, so there is no accountability. Weekly team review of adoption metrics changes behaviour faster than any other intervention.

How do you track GitHub Copilot seat utilisation without manual effort?

Automate seat utilisation tracking by polling the GitHub Copilot REST API weekly, storing last_activity_at per seat, and alerting when a seat crosses 14 days of inactivity — this catches dark seats in two weeks instead of at renewal.

Manually checking the GitHub dashboard monthly is too slow. A seat that goes dark in week two of a 12-month contract will cost you 10 months of spend before you notice. The API gives you everything you need to automate this.

A minimal tracking setup:

1. Weekly cron: pull seat data. GET /orgs/{org}/copilot/billing/seats returns all provisioned seats with last_activity_at. Store this in a table with seat_login, last_activity_at, provisioned_at.

2. Compute activity age. For each seat, calculate days_since_activity = today - last_activity_at. Seats with last_activity_at = null have never activated.

3. Alert at two thresholds. Flag seats at 14 days inactive (early warning) and 30 days inactive (ghost seat — reclaim or investigate). Never-activated seats should flag immediately after a 7-day grace period post-provisioning.

4. Route alerts to the manager, not the developer. Developers do not self-report non-use. Direct-to-manager alerts produce faster remediation.

In our own 29-seat rollout, this approach surfaced 7 developers who had never run a single session within the first two weeks — a 24% ghost rate that translated to $1,400/month in recoverable spend. Read the full ghost seat case study →

GitHub Copilot vs Claude Code: what does each tool expose for team tracking?

GitHub Copilot exposes seat-level last-activity data and aggregate suggestion metrics via a REST API; Claude Code has no built-in team analytics — it requires a local sync agent to capture session data and surface it to managers.

Metric	Copilot native	Claude Code native	CloudByte AI (both tools)
Active users (28-day)	✅ Dashboard + API	❌	✅
Per-developer session count	❌	❌	✅
Ghost seat detection	Partial (last_activity_at)	❌	✅ Auto-alert
Project-level usage breakdown	❌	❌	✅
AI-assisted commit ratio	❌	❌	✅
PR cycle time vs AI usage	❌	❌	✅
Cross-tool unified view	❌	❌	✅
Setup health / broken-sync alert	❌	❌	✅
Export / API for own dashboards	✅ REST API	❌	✅

Claude Code users get richer session data from a local agent perspective — prompt counts, model used, token spend — but this data stays local unless a tool instruments and syncs it. Teams running both Copilot and Claude Code have two separate data silos and no unified adoption view unless they build one or use an analytics layer like CloudByte AI.

How do you get per-developer GitHub Copilot analytics?

Per-developer Copilot analytics require org-admin access to the GitHub REST API; engineering managers without admin credentials need either delegated access or a third-party analytics tool that holds the admin token and exposes filtered views per team.

The GitHub Copilot API returns per-seat data — but the endpoint requires manage_billing:copilot scope, which is typically limited to org owners and billing admins. Most engineering managers do not have this access.

Three practical options:

Option 1: Work with your GitHub org admin. Ask them to set up a read-only service account with billing scope that runs the weekly seat pull. Output goes to a shared spreadsheet or Slack alert. Works well for small teams with a cooperative IT function.

Option 2: Use the GitHub Copilot Enterprise seat management UI. GitHub Enterprise Cloud includes a seat management UI that shows last-activity-at per seat. Org admins can export this as a CSV. Manual, but no API setup required.

Option 3: Use an analytics layer with delegated access. Tools like CloudByte AI hold the GitHub API token at the org level, pull seat data on your behalf, and expose per-team views to engineering managers without requiring them to have admin credentials. This also enables cross-tool views if the team uses Claude Code alongside Copilot.

Privacy note. GitHub Copilot's per-seat API exposes last-activity timestamps and editor/language breakdowns — not the content of suggestions or prompts. This is consistent with most engineering-team analytics policies. Review your org's employee monitoring policy before deploying any tooling that captures activity at the developer level.

What to track per developer each week

Once you have API access, focus on four metrics per developer:

Metric	Why it matters	Red flag threshold
Days since last activity	Primary dark-seat signal	> 14 days
Accepted suggestions / active day	Usage depth, not just breadth	< 3/day
Acceptance rate (accepted / shown)	Are suggestions useful for this developer?	< 20% sustained
Primary language	Cross-reference against team's codebase	Mismatch vs expected

Acceptance rate below 20% sustained for more than two weeks usually means the developer is in a workflow where Copilot adds friction rather than value — worth a short conversation about which tasks they are using it for.