How to Prove GitHub Copilot's ROI Across Your Engineering Team

TL;DR: You want to know whether Copilot usage is actually moving value delivery, but GitHub's own reporting only has visibility into pull request activity. Its user-teams report gives you team-level aggregation only when your team structure lives in GitHub teams, and teams with fewer than five Copilot seats are excluded from it entirely. When structure lives in your HR system or project management tool, the join is yours to build and maintain. There is no ticket or issue linkage at any tier. To prove business value, pull the per-user daily report from the Copilot Metrics API, resolve developer identities across your version control and project management systems, then regress value delivered, such as story points completed, against token spend. Building that pipeline is achievable, but maintaining API connections and identity mapping diverts engineering time. minware normalizes this with pre-built AI impact reports and transparent data lineage for $25/contributor/month, with a free trial available.

Engineering leaders preparing for a board review often arrive with detailed token spend figures and no way to connect that spend to delivery. GitHub's native Copilot reporting shows seat activity, suggestion acceptance rates, lines of code, plus pull request creation and merge counts. It stops at the pull request. Answering whether AI spend is moving roadmap delivery means extracting the per-user usage reports, mapping developer identities across your version control system and your project management system, then correlating token spend against value delivery metrics. This guide walks through those steps and makes the maintenance costs explicit at each stage.

Identifying gaps in native Copilot visibility

The GitHub Copilot admin dashboard tells you whether your team is using the tool and how that usage tracks against pull request activity. Its pull request lifecycle metrics cover creation and merge counts, median time to merge, and review suggestion activity. What it does not show is whether that activity moved a ticket through a sprint, completed a roadmap epic, or shortened time to ship a feature. Understanding software delivery friction requires connecting AI activity to downstream software development lifecycle (SDLC) data, and the native reporting does not ingest your project management system, your sprint structure, or your deployment pipeline.

That boundary moves. GitHub shipped an impact dashboard in July 2026 reporting pull requests merged per user and merge velocity by adoption cohort, built on adoption-phase data the usage metrics API already exposed. Each release pushes the boundary further into territory a single-vendor dashboard can cover, and every release stops at the same place, which is where GitHub's own data ends.

Critical API limitations:

Limitation	Impact on reporting
Reports start December 12, 2025 (org-level confirmed); enterprise-level start date is earlier	No route to usage data predating your tier's start date, regardless of retention
Teams under five seats excluded	Small teams disappear from team-level reports entirely
No HR or project management structure	Team-level aggregation requires a custom identity mapping layer
No ticket or issue correlation	Cannot attribute usage to specific epics, sprints, or roadmap items
No spend-to-outcome mapping	Usage visible but not linked to story points or roadmap delivery
No quality guardrail metrics	Rework rate and change failure rate absent from native reporting

Where team-level aggregation breaks down

GitHub has no native understanding of your HR team hierarchy or project assignments. The API returns usage data at the individual user level, keyed to GitHub login. To aggregate that into team cohorts matching how your org is structured, you write and maintain a mapping layer joining GitHub usernames to project management assignees, HR directory IDs, or cost center codes.

The team-level metrics report, released in May 2026, links a user's GitHub team membership to a given day's usage. Many engineering orgs define team structure in their HR system or project management tool rather than in GitHub, so the join problem remains for them.

The report also carries a floor. Teams with fewer than five seated Copilot users are excluded from it, so squads, platform teams, and newly formed groups disappear from team-level reporting even though their members' individual activity is still visible in the per-user report.

Why usage counts stall at the pull request

Pull requests merged is the metric most teams bring to a board review, and it proves code output rose without saying anything about whether that code delivered value. Acceptance rate and lines of code accepted have the same problem one level further down. The metrics executive reporting needs are grounded in value delivery: story points completed, sprint completion, and roadmap delivery. Connecting Copilot usage to those requires data from your project management system, which native Copilot reporting does not ingest at any tier.

Step 1: Activate GitHub Copilot admin reporting

Before extracting usage data, enable the Copilot usage metrics policy that makes it visible and confirm you hold the right permissions.

Confirming policy and permissions

Copilot usage metrics must be enabled at the enterprise or organization level before the API returns anything. Access requires enterprise owner, billing manager, or organization owner status, or a custom role carrying the fine-grained "View Enterprise Copilot Metrics" permission, as the API documentation sets out. Without the policy active, requests return 401 or 403 rather than data. Whoever owns your enterprise settings does this once, and it is worth confirming before anyone starts building against the API.

Configuring granular usage reporting

Enable user-level telemetry within your Copilot policy settings, which is what produces reporting at the individual contributor level. GitHub's user-teams report then lets you produce team-level breakdowns by joining user data to team membership.

Step 2: Pull data from the Copilot Metrics API

With reporting enabled, the steps below cover credentials, endpoint selection, rate limits, historical coverage, and scheduling.

Scoping and storing API credentials

Scope your token to the tier you are querying. Enterprise endpoints take a classic Personal Access Token (PAT) with the manage_billing:copilot or read:enterprise scope, and organization endpoints take read:org. You can also configure a GitHub App installation token with the Copilot organization permission. Store the token in a secrets manager rather than a configuration file, and rotate it on a schedule aligned with your security policy.

Pulling from the metrics endpoints

Per-user daily metrics come from /orgs/{org}/copilot/metrics/reports/users-1-day, and the team-attributed report sits at /orgs/{org}/copilot/metrics/reports/user-teams-1-day. Both have enterprise equivalents under /enterprises/{enterprise}/. Each row in the user-teams report represents a team membership for a given day. Inner-join the two reports on user_id, day, and entity_id to produce team-attributed data. All three keys must match. entity_id resolves to organization_id at the organization tier and enterprise_id at the enterprise tier.

Users belonging to multiple teams contribute their activity to each one, so guard against double-counting before you aggregate. Note that the beta /usage endpoints were deprecated in February 2025 and the legacy metrics API closed down in April 2026, so scripts pointing at either need updating.

Managing rate limits and pagination

GitHub enforces rate limits on its REST API, surfaced through the x-ratelimit-remaining and x-ratelimit-reset response headers. When the remaining allowance reaches zero, wait until the Coordinated Universal Time (UTC) epoch timestamp in x-ratelimit-reset before retrying. Secondary rate limits work differently. Check the retry-after header first and honor it when present, falling back to exponential backoff with a configurable retry ceiling when it is absent.

Handle pagination by following the Link header's next relation until the final page. Confirm the current API version header before deploying to production, since the endpoint set has turned over more than once since 2025.

Recovering historical data

Organization-level reports are available from December 12, 2025 onward. Enterprise-level reports start earlier, so confirm the date for your tier before scoping a backfill. In both cases the practical constraint is the start date rather than a rolling window. Pull your full available history on first run rather than only going forward from the day your job starts.

Scheduling daily extraction

With the backfill in place, set up a daily job to extract and persist new usage data into your own store. GitHub retains report data for up to one year, so a missed day is recoverable, but your own store is what lets you join Copilot data to ticket and deployment data and retain it beyond GitHub's window. It is also what lets you control your own schema. Treat the daily job as the foundation of the pipeline rather than as insurance against data loss.

Step 3: Standardize identities and token spend across engineering teams

Raw API data maps to GitHub identities rather than to your org structure or project management tool, so a normalization layer is required before the data becomes reportable.

Assigning usage logs to team cohorts

Every record returned by the Copilot API is keyed to a GitHub username. Your project management system, whether that is Jira, Linear, Azure Boards, or GitHub Issues, uses its own internal identifiers. Mapping between them requires a lookup table built and maintained from a combination of HR export and manual correction.

This is where identity fragmentation accumulates quietly. Developers routinely carry different usernames and email formats across version control, ticketing, and AI tooling, and without an explicit resolution layer each variant reads as a separate contributor. Missing or wrong mappings cause AI-assisted work to fall out of sprint and roadmap metrics entirely, making the contribution from AI tooling look smaller than it is.

Defining token spend consistently

Token spend is the dollar cost of AI tool usage. Token consumption is a separate data point, and the two convert using per-model pricing. GitHub moved Copilot to usage-based billing in June 2026, replacing premium request units with AI credits, where 1 AI credit equals $0.01. That gives you a direct dollar figure per model rather than a seat cost to apportion. Where you still need to allocate a flat fee across tools, define one method and hold it across every tool before comparing spend figures.

Automating identity and team resolution

minware automatically links identities across version control, ticketing, and calendar sources, so you do not maintain the lookup table yourself. Its patent-pending hypercube data model also infers team membership from source data or matches source activity to a canonical org hierarchy imported from an HR export. That removes the lookup table you would otherwise build, maintain, and debug every time someone joins, leaves, or changes their username. It also applies to every team regardless of seat count.

Step 4: Join Copilot activity to tickets and epics

With normalized data in place, the steps below link Copilot activity to the tickets, epics, and deployments that delivery reporting depends on.

Connecting source code to AI usage

Copilot usage records land at per-user daily granularity. Connecting that activity to a pull request means matching usage days to branch commit activity, then joining on pull request metadata that references a ticket through a branch naming convention or description. That chain has gaps at every step.

Developers commit manually after AI-assisted drafting, branch names skip the ticket ID, and commit-level AI attribution is unreliable. This behavior is specific to VS Code: it can stamp a Copilot co-author trailer on commits through the git.addAICoAuthor setting. That default is off as of this writing, though it has changed three times in recent releases: off to all in version 1.117, all to a narrower chatAndAgent default in 1.118 as a stopgap, then back to off in 1.119 once the underlying bug, which had attributed non-Copilot completions to Copilot, was fixed. It is not a signal you can assume is present or accurate across a team.

minware's patent-pending hypercube data model uses time-based modeling to recover these hidden associations, as detailed in minware's monitoring tool comparison. When a developer's Copilot usage and commit activity fall in the same window, minware associates that activity with the branch and, through the branch, to the linked ticket and epic, even when the developer omits the ticket ID from the commit message.

Tracking Copilot impact on sprint goals

Weak branch-to-ticket linking causes sprint completion and story point velocity to undercount AI-assisted work. If a developer's AI-generated code lands in a branch with no ticket reference, that work never gets attributed to an epic or a sprint commitment, so delivery metrics look the same regardless of whether AI assistance helped. minware's best practices report surfaces the branch-to-ticket linking rate per team, giving front-line managers a specific, actionable list of pull requests missing ticket links to work through.

Adding deployment data to the analysis

Deployment frequency and lead time for changes can be measured from CI/CD pipeline runs, from Git tags for deployed versions, or from merges to the main branch where no CI/CD data is available. You do not need full CI/CD integration to start correlating Copilot usage with delivery outcomes, though adding deployment data enables the full DORA metric set. minware's project completion report links epic-level burndown and estimated completion to the same data model that powers AI impact reporting.

Confirming the pipeline is ready for analysis

Before analyzing the data, confirm the pipeline is complete end to end. Two guardrail metrics belong in this list even though they haven't come up yet: rework rate, which counts bugs created divided by pull requests merged, and change failure rate, which counts change failures divided by deployments. Both confirm the delivery gain isn't coming at the expense of quality.

• Enterprise owner, billing manager, organization owner, or "View Enterprise Copilot Metrics" role confirmed
• PAT generated with the scope matching your tier (read:org for organization endpoints)
• Copilot usage metrics policy enabled in enterprise or org settings
• Daily scheduled job for data extraction
• External persistence layer (database or data warehouse) for historical data
• Identity mapping from GitHub logins to project management assignees created or automated
• Entity mapping in place linking commits, agent sessions, and pull requests to the tickets and epics they have no structured connection to
• Cost allocation approach defined for token spend reporting
• Analysis methodology defined for correlating token spend with delivery metrics
• Rework rate added to reporting layer
• Change failure rate added to reporting layer
• Branch-to-ticket linking rate reviewed and gaps addressed

Linking Copilot costs to delivery outcomes

Steps 1 through 4 produce a usable dataset. Everything below is analysis rather than pipeline work, which is why it sits outside the numbered sequence. The sections cover the methodology for connecting that data to delivery outcomes and the signals that qualify the result.

Moving past token counts as evidence

Token consumption is an activity metric. It tells you the tool is being used. Presenting rising token counts to a chief financial officer (CFO) has the same weakness as presenting rising pull request counts, which is that both describe output rather than outcome.

The question boards and CFOs actually ask is whether higher spend is buying more delivery, and answering it requires delivery data that usage counts cannot supply. The effect of AI-generated code on change failure rate also means throughput claims without quality guardrails are increasingly difficult to defend.

Validating Copilot spend against value

The methodology that answers this is a linear regression of a value delivery metric against token spend as a continuous variable. Run it with story points completed or roadmap delivery on the Y-axis and token spend on the X-axis, using one data point per team per time period. The slope is the marginal rate, meaning the additional story points completed per additional dollar of spend, and it is the return on investment (ROI) figure itself.

Non-AI work sits at the zero-spend endpoint, so a separate binary cohort comparison is not required, though it works as a supporting check where a genuine non-AI cohort still exists. The R-squared value indicates how much of the delivery variation the spend explains, on a 0-to-1 scale.

Name the confounders before someone else does. Teams that spend more on AI often differ in ways the regression does not capture, because developers choose whether to reach for AI on a given task and early adopters are frequently the strongest performers already. That is why the R-squared value belongs next to the slope in any board material, and why a correlation needs a plausible causal story before it drives a decision.

Reading cycle time and quality as guardrails

Cycle time, measured from a branch's first commit to when its pull request merges, is a workflow guardrail sitting alongside the delivery regression. If token spend rises and story points completed rises with it but cycle time rises too, the extra code volume is likely creating a bottleneck at the review stage. Tracking AI workflow impact with cumulative flow diagrams adds a second visual check on whether AI-assisted work accumulates work in progress (WIP) at any stage.

Rework rate, which counts all bugs created divided by pull requests merged, and change failure rate, which counts change failures divided by deployments, act as quality guardrails confirming speed is not coming at the expense of stability. Both belong in an AI ROI presentation as confirmatory signals rather than as the ROI evidence itself.

Weighing the hidden costs of custom pipelines

The pipeline described above is achievable to build. The sections below cover what it costs to maintain and how that compares against a dedicated platform.

Building your own data stack

A custom GitHub Copilot pipeline looks straightforward on a whiteboard, since it pulls from an API, joins to your ticketing system, writes to a database, and gets queried in a dashboard. In practice it means maintaining compatibility with GitHub's API schema as it evolves, rotating credentials, handling pagination, and updating the identity resolution layer whenever team structure changes. The endpoint set has turned over more than once since 2025.

Sculley et al.'s 2015 paper on hidden technical debt in machine learning systems found it common to incur massive ongoing maintenance costs once pipelines accumulate joins, scrapes, and intermediate outputs. The same pattern applies to any pipeline stitched across several vendor APIs. Those costs land in future engineering cycles rather than in the original build estimate, which is why they rarely appear in the number that justified the build.

Carrying the explanation burden

The less visible cost is the standing obligation to answer "how is this calculated" every time a stakeholder questions a metric. With an internal build, that question lands with whoever built the pipeline, indefinitely. With minware, the minQL formula language makes every metric's calculation visible directly in the UI, and customer success can answer data lineage questions without engineering escalation. That difference compounds across every quarterly review and board presentation.

Comparing vendor and in-house tracking

Dimension	Custom pipeline	minware
Initial setup	Weeks to months of engineering	Hours for data ingest
Ongoing maintenance	Continuous (API changes, credential rotation, identity mapping)	Handled by minware as APIs evolve
Entity resolution	Lookup tables, plus scripts linking commits and PRs to tickets	Automatic identity matching, plus relationship recovery for unlinked records
Custom metric flexibility	Requires engineering escalation	Configurable in the report builder, or customized by CS in ~24 hours
Spend-to-outcome correlation	Build correlation analysis from scratch	Pre-built in the AI impact report
Pricing	Engineering time plus infrastructure	$25/contributor/month (Professional)

Building this pipeline yourself is achievable, and for a small team with a simple, standardized process a custom script may suffice. Once other stakeholders are involved, you need consistent metric definitions across teams, a governance layer that survives personnel changes, and an audit trail that lets you defend every number in a board meeting. That is the point where in-house maintenance costs tend to outpace a dedicated platform.

"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 minQL 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

Addressing your Copilot data concerns

The sections below address two practical concerns that arise when teams begin tracking Copilot usage at scale.

Standardizing messy engineering data

Messy data is not a reason to postpone tracking. The gaps are the first thing the measurement surfaces, and closing them improves every downstream metric including the AI ROI regression, so there is no sequencing argument for cleaning up first.

Using guardrails to prevent metric gaming

Every throughput or value metric in an executive report needs a quality counterpart to prevent gaming that inflates numbers without improving delivery. Pair pull requests merged with rework rate, since rework rate already uses pull requests merged as its denominator, and pair deployment frequency with change failure rate. minware's quality reports cover bug creation, prevention, and resolution. The hypercube data model lets you break down any metric by the dimension most relevant to the suspected gaming pattern.

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

Putting this into practice

The Copilot Metrics API gives you usage. Everything that turns usage into a board-ready answer sits downstream of it, in the identity layer that maps GitHub logins to your org, the ticket linkage that connects code to commitments, and the regression that ties spend to delivery. Whether you build that or buy it, the deciding question is the same: who owns the entity mapping and the "how is this calculated" conversation a year from now, when the API has changed again and the person who wrote the script has moved teams.

Start a 14-day free trial at minware.com, no credit card required, and connect your first data source. Explore the pre-built AI impact reports with your own team's data, including the token spend to delivery regression, before talking to anyone on our team.

FAQs

How long does GitHub retain Copilot usage data via the API?

GitHub retains report data for up to one year from the current date. Organization-level reports are available from December 12, 2025 onward; enterprise-level reports start earlier, so confirm the date for your tier before sizing a backfill window. In both cases the start date is the practical constraint rather than a rolling window. Persisting data to your own store still matters, because that is what lets you join Copilot data to ticket and deployment data and retain it beyond GitHub's window.

Can I track Copilot usage by team natively?

Only when your teams are defined as GitHub teams, and only when they have at least five Copilot seats, since smaller teams are excluded from the user-teams report. Where team structure lives in your HR system or project management tool, aggregation requires a custom identity mapping layer. minware automatically links identities across systems and infers team membership from source activity, with no seat-count floor.

What permissions are required to access the Copilot Metrics API?

You need enterprise owner, billing manager, or organization owner status, or a custom role with the fine-grained "View Enterprise Copilot Metrics" permission. Token scope depends on tier: manage_billing:copilot or read:enterprise for enterprise endpoints, and read:org for organization endpoints.

What is the right methodology for proving Copilot ROI to a CFO?

Run a linear regression of story points completed or roadmap delivery against token spend as a continuous variable, with one data point per team per time period, and read the slope as the marginal ROI figure. Report the R-squared value alongside it, and name the selection effects that could explain the relationship. Pair the result with rework rate, change failure rate, and cycle time as supporting guardrails to confirm quality and workflow are not deteriorating alongside the delivery gain.

Does messy Git data prevent meaningful Copilot tracking?

Messy data delays accuracy without blocking you from starting, because best practice metrics like branch-to-ticket linking rate surface exactly where the process breaks down and give managers a specific list of gaps to close. Fixing those gaps improves every downstream metric, including the AI ROI regression, without requiring a full data cleanse before analysis begins.

Key terms glossary

Token spend: The dollar cost of AI tool usage, tracked separately from token consumption, which is the count of tokens processed. For developers on flat-rate plans, reported spend may be more or less than the amount actually paid, since a monthly seat fee has to be allocated across usage.

Story points completed: The total of the story points field for completed tickets. It carries no sprint scoping of its own, which is what makes it usable as the value delivery metric in a regression against token spend across teams and time periods.

Rework rate: A quality metric counting all bugs created divided by pull requests merged. It is broader than DORA's own rework rate, which counts only deployments intended to fix a bug divided by total deployments, so it captures quality problems that change failure rate misses.

Cycle time: A workflow metric measuring the duration from a branch's first commit to when its pull request merges, used as a guardrail to confirm that increasing AI-generated code volume does not create review bottlenecks.

Linear regression: A statistical method that fits a straight line to data points to model the relationship between variables, producing a slope that indicates how much the dependent variable changes per unit change in the independent variable, and an R-squared value indicating the proportion of variance in the outcome explained by the model (from 0 to 1).

Entity resolution: The process of matching related but disconnected records, a developer's identity across systems with different usernames or emails, and activity records such as commits, tickets, pull requests, and AI agent sessions that carry no structured link between them, so activity attributes correctly to the right team member, team cohort, and delivery item.