Copilot Has Repo-Level Metrics Now. What Should Teams Measure?

By Greg Nowak. Last updated 2026-07-29.

GitHub has filled a useful gap in Copilot reporting. Its usage metrics API can now show, by repository and day, pull requests created or merged by Copilot cloud agent and pull requests reviewed by Copilot code review. It also reports review suggestions by comment type and whether teams applied them.

That gives engineering leaders a much clearer view than an organization-wide adoption number. You can see where AI-assisted work is entering the delivery process and which Copilot features teams actually use.

What you cannot see is whether any of that work helped. Repository-level metrics answer where Copilot was active. They do not prove that delivery became faster, software became more reliable, or costs came down.

The sensible approach is to use Copilot data as one part of an operational scorecard. The goal is not to make AI usage look impressive. It is to find the repositories and types of work where Copilot produces acceptable results at a cost the business can defend.

Keep activity and impact separate

GitHub’s repository-level endpoints provide daily breakdowns for organization and enterprise reports. They identify repositories and record pull-request creation, review, merge, and suggestion activity involving Copilot.

These are useful workflow signals. More agent-created pull requests may mean developers have found suitable tasks for the agent. More Copilot-reviewed pull requests may point to broader review coverage. Applied suggestions show that Copilot’s comments made it into the change process.

None of those numbers is an outcome measure.

The details of GitHub’s definitions matter here. Its usage metrics reference says repositories without relevant pull-request activity are omitted from a daily repository report. Created and merged pull requests are counted on the day of that one-time event. A pull request reviewed on several days may appear on each of those days. Adding daily figures together without accounting for those rules can produce a polished but misleading dashboard.

A scorecard that management can use

A practical scorecard needs four layers. Together, they show whether Copilot is being used, where it enters the workflow, what happened next, and what the organization consumed to get there.

Use repository data to find the next question

The strongest use for repository-level reporting is segmentation. It can reveal repositories with steady Copilot-created pull-request activity, repositories where code review is the main use case, and repositories with little or no recorded activity. That gives the team a focused set of places to investigate.

The differences may come down to repository type, delivery practices, test coverage, or the suitability of the work being delegated. A documentation repository and a high-risk production service should not be expected to produce the same pattern.

Ratios help, provided their denominators remain visible. Useful examples include the share of created pull requests attributed to Copilot cloud agent, the share of Copilot-created pull requests that are merged, and the share of Copilot review suggestions that are applied. GitHub also provides median time-to-merge fields for all merged pull requests, Copilot-authored pull requests, and Copilot-reviewed pull requests.

Those measures tell you more than raw counts, but small samples can still flatter the result. One agent-created pull request followed by one merge produces a 100% observed merge share. It does not produce a reliable performance conclusion. Show the numerator and denominator, look at multi-week trends, and mark sparse samples clearly.

Put reliability next to throughput

A 2026 repository-level study of AI-bot footprints in GitHub Actions analysed 61,837 workflow runs from 2,355 repositories. The authors found substantial differences between agents and reported a negative repository-level correlation between agent-contribution frequency and workflow success rate.

This is a warning signal, not a universal verdict. The study covers a particular dataset, and correlation does not show that higher agent activity caused lower reliability. It does reinforce an important point for internal reporting: more agent activity is not automatically a better delivery result.

Put failed checks, repeated workflow failures, rework, and incidents beside agent activity. If Copilot-created pull requests rise while failed checks or corrective work also increase, the team has a task-selection or review-control problem to investigate. If activity rises, reliability stays within agreed limits, and lead time improves, there is a more credible case for expanding the rollout.

Track both parts of the bill

Cost has become a more immediate concern. GitHub announced that, from June 1, 2026, Copilot plans use AI-credit-based billing. Copilot code review also consumes GitHub Actions minutes in addition to AI credits, and organizations and enterprises can set user-level budgets.

Code review therefore creates two consumption signals: AI credits and execution capacity. A rollout report that follows only licences or credits can miss its effect on Actions. A cost dashboard without repository activity has the opposite problem: it cannot show which workflows are consuming capacity or whether that consumption is producing accepted work.

GitHub also lets Copilot Business and Enterprise users see credits used during the billing cycle, including users without an individual budget. The API reference exposes per-user AI-credit consumption, but describes it as consumption data rather than an invoicing total. It does not break that usage down by feature, model, or surface. Operational reporting and financial reconciliation should remain separate, even when they sit on the same dashboard.

Build the report around real decisions

A lightweight reporting pipeline can pull the daily organization or enterprise repository report, retain its source date and repository identifiers, and join it with existing pull-request, Actions, quality, and incident data. Weekly or monthly views can then be produced without discarding the original event definitions.

Keep the first dashboard small. Show Copilot activity by repository, merge and review ratios with their denominators, median merge times, failed-check or rework signals, AI-credit consumption, and Actions usage. Annotate missing repositories, null medians, reporting-scope differences, and changes in rollout policy. Those details are not housekeeping; they determine whether readers can trust the comparison.

Agree on the decisions the scorecard must support before expanding it. The result might justify rolling Copilot out to another group of repositories. It might show that tests need attention first, that certain tasks should no longer be delegated, that review controls need changing, or that budgets need adjusting. A metric that cannot inform one of those choices probably does not need to be on the page.

This is where a focused freelance operator can be useful. Greg can help connect the GitHub APIs to the delivery and cost data teams already have, then turn that reporting into a scorecard people can use in rollout and budget discussions. The value is not another dashboard. It is a clearer basis for deciding where Copilot belongs, under what controls, and at what cost.

Related on GrN.dk

• Background AI Tasks Need Queues, Not Just Longer API Calls
• OpenAI Is Retiring Agent Builder: Save the Workflow, Not Just Prompts
• Search Console Can See Social Posts—Your Reports Need a New Map

Need help with this kind of work?

Build a defensible Copilot rollout scorecard Get in touch with Greg.

Sources

• Repository-level GitHub Copilot usage metrics generally available
• Data available in Copilot usage metrics
• Updates to GitHub Copilot billing and plans
• Copilot users can now see AI credits used per billing cycle
• Reliability of AI Bots Footprints in GitHub Actions CI/CD Workflows