GitHub Copilot Metrics API Now Tracks Usage Down to the Repository

GitHub has expanded its Copilot usage metrics REST API to report activity at the repository level, moving beyond the organization and user summaries that were previously the limit. Two new endpoints, released as generally available on July 17 2026, return a daily per-repository breakdown of pull request activity for Copilot coding agent and Copilot code review, covering both enterprise and organization scopes.

What happened

Detail	Value
Release status	Generally available
Release date	July 17, 2026
New endpoints	2 (enterprise and org scopes)
Reporting granularity	Daily, per repository
Features covered	Copilot coding agent, Copilot code review

GitHub’s Copilot metrics REST API previously stopped at the organization and user level. The new endpoints go one level deeper, giving teams a daily snapshot of exactly which repositories are seeing Copilot activity.

The two endpoint paths are:

• Enterprise: GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD
• Organization: GET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD

Each response includes pull requests created and merged by Copilot coding agent, plus pull requests reviewed by Copilot code review with suggestion counts broken down by comment type.

Who can access these reports?

Access is gated by role. Enterprise owners, billing managers, and organization owners can all call these endpoints. Anyone with a custom organization or enterprise role that includes the “View Copilot Metrics” permission also qualifies. The Copilot usage metrics policy must be enabled at the enterprise or organization level before the endpoints return any data.

Why it matters

Before this change, a team could see how many seats were active but had no clean way to tell which repositories were actually benefiting from Copilot. You might have Copilot enabled across 200 repos while 190 of them produce zero agent-driven pull requests.

Repository-level data changes that. GitHub describes these endpoints as the foundation for “repository insights and AI-readiness reporting,” meaning teams can now point enablement efforts at the repos most likely to see a return. For engineering managers and platform teams, that is a more defensible way to justify seat spend or expand rollouts.

It is also useful in the other direction: if a repo generates a lot of Copilot-created pull requests that are not being merged, that is a signal worth investigating before the next billing review. Tracking AI agent adoption across a codebase is a growing concern for teams building with tools like these, and you can see more context on that topic in our coverage of the gap between AI agent deployment and real-world adoption in enterprises.

Our take

This is a straightforward, useful update. Aggregate org-level metrics were always a bit too blunt for decisions that matter: budget allocation, which teams need more onboarding, which repos have the right CI setup to actually use Copilot coding agent effectively. Per-repo daily data is the right granularity for those calls.

The caveat is that raw pull request counts are a proxy, not a quality measure. A repo could have 50 Copilot-created PRs that are all getting closed without merge. Teams should pair this data with their existing merge rate and review cycle metrics before drawing conclusions.

If your organization is still figuring out how to wire Copilot metrics into broader dashboards or automate reporting workflows, that kind of integration sits squarely in the territory our workflow automation service covers.

What to do about it

1. Confirm the Copilot usage metrics policy is enabled in your enterprise or organization settings.
2. Check that the right roles (enterprise owner, org owner, or custom “View Copilot Metrics” role) are assigned to whoever will query the API.
3. Make a test call to the org endpoint for yesterday’s date to verify the response shape before building any dashboards.
4. Cross-reference per-repo PR counts against merge rates to identify repos where Copilot is generating activity but not value.
5. Use the findings to prioritize enablement or training for the repos that show low activity but high potential.

Start with a single org endpoint call for one day’s data before committing to a full reporting pipeline.

Source: GitHub Changelog