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

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.

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.

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 PMS 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.

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 PMS.

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 PMS 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.

What to track per developer each week

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

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.

---

FAQ: tracking GitHub Copilot usage across engineering teams

How many developers actually keep using GitHub Copilot after the first month?

Industry data and CloudByte PMS pilot observations consistently show 30–40% seat dark rates within 60 days. Developers activate their account and try Copilot for a sprint or two, then usage drops without habit reinforcement or manager visibility. GitHub's active-user definition (at least one accepted suggestion in 28 days) means a developer can appear "active" while using the tool for only 20 minutes a month.

What is a good GitHub Copilot adoption rate?

A healthy adoption rate is 70%+ of licensed seats showing meaningful weekly usage (5+ accepted suggestions per week). Teams below 50% active seats within 90 days of rollout have either a tooling issue or a habit gap. Teams above 85% should focus on optimising usage quality rather than breadth.

Can I see per-developer GitHub Copilot usage without admin access?

No. Per-developer data requires org-level admin access to the GitHub REST API (manage_billing:copilot scope). Individual developers can see their own stats, but managers need admin credentials or a third-party tool that holds admin access and exposes filtered views.

How often should I review GitHub Copilot seat utilisation?

Weekly for anomaly detection, monthly for adoption trends and renewal decisions. GitHub's 28-day active-user window aligns with a monthly review. Quarterly reviews should benchmark adoption against DORA metric improvements to confirm the investment is delivering value.

What's the difference between GitHub Copilot active users and seat utilisation?

GitHub counts a developer as "active" if they accepted at least one suggestion in 28 days — a low bar. Seat utilisation is the fuller picture: consistent weekly usage, session depth, and acceptance rate trend, not just whether the developer touched the tool once in a month.

How do I track GitHub Copilot usage alongside Claude Code?

GitHub Copilot and Claude Code expose data through different channels — Copilot via the GitHub REST API, Claude Code via local session logs. A unified view requires an analytics layer that ingests both and normalises metrics to a common schema. CloudByte PMS instruments both tools via a lightweight sync agent, giving managers per-developer data across both AI coding tools in one dashboard.