GitHub Copilot Usage Tracking & Metrics: The Complete Engineering Leader's Guide

TL;DR: GitHub Copilot adoption climbs, code volume climbs with it, and roadmap delivery stays flat. Leadership wants to know whether the annual spend is shipping features faster. Copilot's native exports and usage metrics API do not answer that question. They give you activity measured by seat counts, prompts sent, and pull requests merged, but not whether that activity delivered value. The defensible return on investment (ROI) metric is completed work items (e.g. story points) per dollar. That number is the slope of a regression across your teams and time periods, reflecting the marginal value gained from each additional dollar spent. Pair it with rework rate and cycle time so a delivery gain doesn't mask a quality problem.

This guide walks through getting the data (native exports and the API), building the dashboard, and presenting the result in your next executive review.

Understanding why Copilot metrics matter for engineering leaders

Knowing which Copilot metrics carry weight in an executive review starts with knowing what they measure and where they stop.

Proving return on investment to the board

Engineering leaders are under real pressure to justify AI tooling costs during budget reviews. GitHub's admin panels and metrics API surface plenty of numbers, so data volume is rarely the constraint. The constraint is presenting numbers a chief financial officer (CFO) or board member can evaluate as financial evidence.

Activity counts and code-output volume leave the actual question unanswered: is delivery improving in proportion to what we are spending?

Separating activity from delivery evidence

Seat utilization and prompt counts measure activity. They tell you the tool is being used and stop there. The metric teams more often bring to a board is pull requests merged, which measures code output volume and carries the same gap. More code arriving is weak evidence that more value shipped.

ACM Queue's SPACE of AI research is blunt about it, finding that organizations doubling down on lines-of-code metrics to track AI's impact are using a measure that is neither statistically valid nor meaningfully connected to outcomes such as software quality or delivery speed.

Correlation is what closes the gap. Run a linear regression plotting a value delivery metric, such as story points completed, against token spend across teams and time periods, then read the slope as the marginal value delivered for each additional dollar. The rest of this guide covers how to get the data behind that regression, then how to run and present it.

Accessing Copilot data exports

GitHub Enterprise administrators can export Copilot usage data directly from the admin panel. The native view surfaces seats assigned, active users, prompts sent, and aggregate acceptance rates.

These are activity metrics. They tell you whether a seat is being used, and they stop short of telling you whether the work it produced moved delivery. Acceptance rate has a further limit worth knowing: it measures a suggest-and-accept interaction, so it describes less and less of the work as agent-driven usage grows.

For license audits, the native view is a useful starting point. For ROI reporting, it is a dead end, GitHub's own dashboard stops at activity counts and never reaches delivery value.

Using the Copilot usage metrics API

Programmatic access requires configuring the right credentials, understanding the payload, and knowing how far back the data goes.

Configuring API credentials and access

The Copilot usage metrics API has two tiers. Organization owners can query organization-level endpoints (/orgs/{org}/copilot/metrics/reports/...) directly with a personal access token (PAT) scoped to read:org, no enterprise plan required. Enterprise Cloud customers get a second, enterprise-wide tier (/enterprises/{enterprise}/copilot/metrics/reports/...), which requires the Copilot usage metrics policy set to Enabled everywhere under AI Controls, queried by enterprise administrators or billing managers.

If your organization isn't on GitHub Enterprise, use the organization-level endpoints instead.

Mapping Copilot API fields to metrics

The Copilot usage metrics payload exposes per-user, per-day fields for interactions, code generation, and lines changed. Four matter most for delivery correlation:

• user_initiated_interaction_count: explicit prompts sent to Copilot

• code_generation_activity_count: distinct Copilot output events generated

• loc_added_sum: lines of code actually added to the editor

• ai_credits_used: credits consumed by the user in the reporting period

That last field carries the dollar figure behind every ROI claim in this guide. The Optimizing Copilot seat allocation and spend section below explains why, seat usage itself isn't a named payload field, but the number of active users each period implies it. The payload also carries pull request activity, including pull_requests.total_merged and median_minutes_to_merge. Those are useful. They remain throughput and workflow measures with no link to your tickets, sprints, or roadmap epics. Connecting them requires a separate normalization layer.

Managing data availability and storage

Copilot usage metrics reports go back to October 10, 2025, with historical data accessible for up to a year from the current date. Each report covers a complete 28-day period ending on the most recently processed day, and data may appear up to three full UTC days behind.

A year of history covers most board questions. It does not cover a multi-year trend, and it is GitHub's window rather than yours, so teams building a long-run correlation persist the daily records into their own warehouse.

Persisting Copilot data beyond GitHub's window

Writing daily scripts to pull and store that data is where the custom engineering burden begins. You need a scheduled job to capture each day's records, a schema that absorbs field additions when GitHub updates the payload, and a join layer that resolves GitHub user logins to Jira assignees. Each task carries ongoing maintenance, and that cost compounds faster than most teams expect when they start the build.

Optimizing Copilot seat allocation and spend

License efficiency depends on knowing what Copilot actually costs per person, which seats are active, and how to act on that information.

Understanding Copilot's usage-based billing

Since June 2026, every Copilot plan bills on usage. Each plan carries two components of GitHub AI Credits: base credits that match the subscription price and are fixed each month, and a flex allotment that is an additional variable amount on top of the base. One credit is one cent, and credits are consumed against token usage at published per-model rates. Copilot's current per-plan pricing determines your base credit allotment, check it directly rather than relying on a fixed figure here, GitHub adjusts these periodically.

This matters more than it looks. Under the old flat-rate seat model, per-user cost was constant, so no dollar figure varied by developer for you to correlate against anything. The ai_credits_used field now gives you genuine per-user dollar spend, which is exactly the continuous variable the regression later in this guide needs.

One caveat belongs in any figure you present. Until a team exceeds its included allotment, credits consumed and dollars billed are different numbers. A developer burning $12 of credits on a seat still costs the full current seat price, $19 per user per month on Copilot Business as of this writing. Say so when the number carries weight, because a finance reviewer will find it otherwise.

Detecting underutilized Copilot seats

Filter the metrics response for users whose code_generation_activity_count and loc_added_sum both read zero across a 30-day window. Those users hold a seat and generate no Copilot output. At the current Copilot Business seat price, $19 per user per month as of this writing, ten inactive seats works out to $2,280 a year.

Measuring cost per active seat

Divide your monthly Copilot invoice by the count of users with at least one interaction event in the period. That gives cost per active seat, which is a license-efficiency figure. It tells you what you are paying per active user and says nothing about what that spend delivered, so keep it out of the ROI section of your board deck.

Reassigning unused Copilot licenses

A practical reallocation policy works in three steps:

1. Flag inactivity: Identify contributors with zero Copilot activity across 30 days using the API export.

2. Confirm with the contributor's manager: Inactivity may reflect a sprint with no coding work rather than tool abandonment.

3. Reallocate to a waitlist: Move the seat to a contributor with an active ticket backlog and regular pull request activity.

Building a Copilot dashboard

A dashboard that holds up in an executive review involves decisions about which metrics to include, how to connect data across sources, and whether to build that connection in-house.

Choosing which metrics carry ROI weight

The table below defines the metric tiers and clarifies which ones carry ROI weight.

Tier	Metrics	Use for ROI?	Why
Activity	Seats active, prompts sent	No	Measures tool usage
Throughput	Pull requests merged, commits, lines of code	No	Measures code output volume
Value delivery	Story points completed, roadmap delivery	Yes	Measures value delivered against commitments
Workflow	Cycle time, work in progress (WIP)	Supporting	Explains where delivery is slowing
Quality	Rework rate, change failure rate	Supporting	Explains whether output quality held

Handling the integration work behind a dashboard

Loading GitHub's metrics export into a business intelligence (BI) tool requires an extract, transform, load (ETL) step that pulls newline-delimited JSON (JSONL) daily, flattens the payload into a relational schema, and joins on a shared user identifier.

The practical problem goes beyond matching names: you also need to determine which commits and pull requests belong to which ticket, and which agent sessions were involved. Producing correct attribution requires a custom mapping and linking layer, and that layer needs maintenance as team members change roles or accounts.

Reviewing example Copilot dashboards

A basic Copilot dashboard built from the native export shows seat utilization, acceptance rate, and lines of code accepted over 28 days. This view is useful for license audits and is the same view GitHub's own admin panel provides.

minware's pre-built AI impact reports go further. They connect Copilot usage data to story points completed, cycle time, and rework rate in the same normalized data model, replacing the join-and-reconcile step with a report you can run against live data. Those reports read from data minware ingests nightly, typically between 2 and 7 AM Eastern, so the dashboard reflects delivery through the prior day. An on-demand ingest is available when a board deck needs fresher numbers, and completes in 30 minutes up to several hours depending on the size of the organization.

Quantifying Copilot spend against delivery outcomes

Translating Copilot cost data into a defensible ROI figure takes a regression. The sections below cover the method, how to read the output, and which guardrail metrics belong alongside it.

Correlating AI costs with delivery value

The ROI methodology is a linear regression of a delivery metric against token spend. Each regression fits one metric pair, so correlating spend against three outcomes means three regressions.

The model needs data points that differ across teams and time periods. minware's AI impact report runs these regressions across your connected data, without requiring you to export CSV files and build the model in a spreadsheet.

Reading the regression slope and R-squared

The slope is the change in story points completed per additional dollar of token spend. If the slope reads 0.01, each additional dollar is associated with 0.01 additional story points completed per team per period, in other words, roughly one story point for every $100 spent. That marginal figure is the ROI answer you bring to a finance review.

The R-squared value tells you how much of the variation in story points completed the spend actually explains. An R-squared of 0.70 means spend differences explain 70% of the variation in delivery across your teams. A low R-squared simply means token spend is not strongly correlated with delivery, it does not by itself identify what else is. If spend is not driving increased value delivery, look at supporting metrics like sprint completion or work in progress for a likely reason, rather than assuming a connectivity gap. PRs traceable to ticket improves the accuracy of cost attribution to specific tickets, but is not required for the regression itself, minware surfaces it in its best practices report for that narrower purpose.

A slope is an association rather than a cause, so name what else differs between your high-spend and low-spend teams before the number carries a decision. Self-reported impact is a particularly weak substitute. In a randomized trial at the early-2025 model frontier, developers misjudged their own speedup badly: they forecast a 24% speedup and reported a 20% speedup afterward, while measured completion time actually slowed down 19%.

Tracking delivery trends and quality guardrails

Rising spend with flat delivery is the signal that prompts a deeper look at where the friction lives.

Every delivery or throughput gain needs a quality counterpart beside it. DORA's 2025 State of AI-assisted Software Development found that higher AI adoption is associated with an increase in both software delivery throughput and instability, which is why a delivery gain read on its own can mislead. Rework rate, measured in minware as bugs created divided by pull requests merged, is the counterpart to pull requests merged and gives a broader quality check than change failure rate alone.

Tracking cycle time as a guardrail

Cycle time, the span from a branch's first commit to its pull request merging, is the second guardrail. A delivery gain that coincides with cycle time stretching out means the team is trading speed for volume, work is piling up mid-flight even as more of it eventually ships. Watch cycle time alongside rework rate in the same period as your ROI figure, a Copilot spend increase that holds both steady is a materially stronger result than one that only holds rework rate steady.

If value delivery rises while rework rate also climbs, the AI-assisted code is creating quality debt that will slow future sprints. Cumulative flow diagrams provide a visual check on whether WIP is accumulating at any stage as token spend increases. Track rework rate and cycle time in the same reporting period as your delivery metrics.

"Minware gives us clear visibility into code quality, defect rates, and development health with quality SDLC metrics." - George V. on G2

Normalizing disparate delivery data

Copilot usage, commits, and tickets have to describe the same people doing the same work before any correlation analysis can run. Two problems sit in the way: missing links between records, and the same contributor appearing under different identifiers.

Recovering links that were never recorded

Linking Copilot usage to specific Jira tickets is harder than it looks. Developers often have several tickets in progress at once, and commits do not always carry a ticket ID in their pull request.

minware's patent-pending hypercube data model recovers these hidden associations by modeling what commit and ticket each contributor was working on at any given time, then associating usage with the most probable ticket context. Explicit branch-to-ticket linking still improves accuracy, because developers frequently write code before marking a ticket in progress. The two work together.

Time-based recovery means you don't have to wait for clean source data before starting analysis.

Resolving disparate contributor identities

The same contributor appears under different identifiers across GitHub, Jira, and Copilot. The common case is a developer whose name and email differ entirely across systems, with no shared field to match on. The awkward case is two people who share a first and last name.

When matching relies on display names or email addresses that do not align, attribution drops silently from your regression inputs. minware resolves these mismatches automatically across connected sources, so Copilot usage, commits, and tickets share a consistent contributor identity without you building a mapping table. A manual override is available in the account settings for edge cases the automatic matching cannot resolve.

Weighing build vs. buy

Normalization and ongoing API maintenance are the work that decides whether you build this yourself. The comparison below covers what each path costs, and the section after it covers the cost most build estimates leave out.

Comparing a custom pipeline against a platform

Capability	Custom pipeline	minware
Initial setup	Weeks of engineering time	Self-serve connection, first reports after initial backfill
API maintenance (GitHub, Jira schema changes)	Ongoing engineering hours	Handled by minware
Identity and data resolution across systems (commits, tickets, PRs, agent sessions)	Custom mapping tables, manual maintenance	Automatic, with manual override for edge cases
Historical backfill	Manual rebuild per source	1 year (Professional), unlimited (Enterprise)
Custom metric definitions	Code changes, requires engineering	Report configuration, or customer success support, typically resolved in minutes to hours
Delivery correlation across sources	Full data engineering build	Pre-built regression reports
Support	Owned internally, troubleshooting falls to your team	Backed by minware customer success

One honest caveat on the right-hand column. The pre-built reports cover the common cases. A question specific to how your organization works still needs a report or metric definition configured for it, either by you in the application or by a customer success agent. That configuration effort is a real constraint alongside normalization, though a smaller one. It is typically measured in a call plus a turnaround rather than an engineering sprint.

Understanding the hidden costs of custom pipelines

The recurring cost most teams underestimate is explanation. Someone has to answer "how exactly is this calculated?" for every stakeholder who looks at a number and asks a follow-up question. With an internal pipeline, that question escalates to whoever built it, indefinitely.

With minware, every metric formula is visible and editable in the application, so a customer success agent can answer methodology questions in minutes without engineering escalation. This is where most purpose-built analytics platforms fall short: they assert accuracy without showing the calculation.

"What I like best about minware is its flexibility. The platform comes with a great set of engineering reports out of the box, so you can start getting value immediately. At the same time, those reports are highly customizable, and minware's query language makes it possible to build your own metrics and dashboards tailored to your team's workflow rather than being limited to predefined reports." - Verified user on G2

Running the Copilot ROI playbook

Proving Copilot ROI to a skeptical board means moving past seat counts and code volume to a correlation between token spend and delivery outcomes. Four steps get you there.

1. Connect the sources: Connect Copilot, your version control system, and your project management system to a shared data model.

2. Confirm identity and data resolution: Check that contributor activity, and the ticket, commit, PR, and agent-session links behind it, appear consistently across all three sources before you trust any aggregate.

3. Run the regression: Regress story points completed against token spend across teams and time periods, then read the slope.

4. Pair the slope with a guardrail: Report rework rate and cycle time in the same period so the delivery claim carries quality context.

Start the executive review with the result. "Each additional dollar of Copilot spend is associated with X story points completed per team per sprint, with an R-squared of Y." Follow with the guardrail: "Rework rate held steady at Z%, so the delivery gain did not create quality debt." Then name your largest confounder before someone else does. That sequence answers the ROI question and the quality question in one block.

Closing the loop on Copilot ROI

Copilot's own exports tell you the tool is being used, and a year of metrics history gives you a real base to work from. Turning that into an answer your board accepts takes one more step: connecting usage to the tickets and roadmap items your organization actually commits to, then reading the relationship as a slope with a quality metric beside it. That is the difference between reporting that Copilot is adopted and reporting what it delivered.

Start a 14-day free trial at minware.com, no credit card required, and connect your first data source.

FAQs

How far back does GitHub Copilot usage data go?

Reports are available from October 10, 2025, with historical data accessible for up to a year from the current date. Each report covers a complete 28-day period ending on the most recently processed day. Teams building a multi-year correlation persist the daily records into their own warehouse, because the window is GitHub's rather than yours.

Why can't I use pull requests merged or lines of code as my Copilot ROI metric?

Pull requests merged and lines of code are throughput metrics that measure code output volume. They can increase while sprint completion and roadmap delivery stay flat, meaning more code is arriving without more value being shipped. The ROI evidence is a regression of a value delivery metric such as story points completed or roadmap delivery against token spend, read off the slope, with rework rate alongside it as a quality guardrail.

How do I compare AI-assisted work to non-AI work without biasing the result?

Use token spend level as a continuous variable rather than splitting teams into AI and non-AI groups. Non-AI work sits at the zero-spend endpoint of the same regression and is included automatically. If you do run a binary cohort comparison, account for person-level selection, where early adopters tend to be stronger performers, and task-level selection, where developers tend to use AI on simpler work. Both make Copilot look better in a raw comparison than the regression shows.

How long does it take to get meaningful delivery data into minware after connecting GitHub and Jira?

The initial backfill covers one year of historical data on Professional or unlimited history on Enterprise, and it can take several hours depending on repository and ticket volume. minware surfaces no data until the backfill completes, so the first usable reports appear when the full backfill finishes. After that, nightly incremental loads keep delivery data current through the prior day.

What is the difference between minware and building a custom Copilot analytics pipeline?

A custom pipeline requires an initial engineering build plus ongoing maintenance as GitHub, Jira, and Copilot change their APIs and schemas. It also needs a custom identity and data-linking layer to match GitHub logins to Jira assignees and connect the work items across tools, not just the individuals. minware handles all three, starting at $25 per contributor per month for the Professional plan with no seat minimum, compared with platforms that gate evaluation behind a sales call or set a contributor minimum before you can start. A self-serve 14-day trial is available with no sales call required before you evaluate with your own data.

Key terms glossary

Story points completed: The total of the story points field for completed tickets in a period. It is a value delivery metric and is the outcome variable in the ROI regression described in this guide.

Rework rate: minware measures rework rate as bugs created divided by pull requests merged, providing a broader quality signal than change failure rate. It is used as a guardrail alongside delivery metrics in AI ROI reporting to confirm that rising output is not creating quality debt.

Token spend: The dollar cost of AI coding tool usage in a given period. Token spend and token consumption, meaning the count of tokens used, are separate data points. On plans with an included credit allotment, credits consumed and the amount billed can differ until the allotment is exceeded.

GitHub AI Credits: The unit GitHub has billed Copilot usage in since June 2026. Each plan carries two components: base credits that match the subscription price and are fixed each month, and a flex allotment that is an additional variable monthly amount on top. One credit is one cent, and credits are consumed against token usage at published per-model rates.

Linear regression: A statistical method that fits a line to a set of data points to describe the relationship between two variables. In AI ROI analysis, it fits story points completed against token spend across teams and time periods. The slope represents story points per dollar.

R-squared (R²): A value between 0 and 1 describing how much of the variation in the outcome metric the predictor explains. An R-squared of 0.70 means token spend differences explain 70% of the variation in story points completed across teams.

Cycle time: The duration from the first commit on a branch to when the pull request merges. It is a workflow metric used as a guardrail in AI ROI reporting.

Work in progress (WIP): A workflow metric counting the tickets or pull requests actively in progress at a given time. It explains where delivery is slowing and should not be used as the primary evidence of AI ROI.

Hypercube data model: minware's patent-pending data architecture that links every software development lifecycle (SDLC) artifact through a shared identity and time reference, covering commits, pull requests, tickets, epics, and AI usage records.