GitHub made repository-level Copilot usage metrics generally available on July 17, 2026. The change affects enterprise and organization administrators who need to see where Copilot coding agent and Copilot code review are active, rather than relying only on organization- or user-level totals. Two REST API endpoints now return a daily repository breakdown of agent-created and merged pull requests, reviewed pull requests, and review suggestions by comment type. The practical consequence is better targeting for enablement and governance: teams can identify active, inactive, or unusual repositories. These counts do not prove code quality, developer productivity, or return on investment, so they should be paired with repository outcomes and human review.
Key takeaways
- GitHub’s new reports provide one complete day’s Copilot coding-agent and code-review activity, grouped by repository.
- Separate endpoints cover an enterprise and an organization; both require a
dayquery inYYYY-MM-DDformat. - Access is limited to eligible owners, billing managers, or custom roles with the relevant Copilot metrics permission. The Copilot usage metrics policy must also be enabled.
- The report can show where agentic pull-request work happens, but it does not establish whether that work was correct, valuable, or faster.
- Use repository metrics to choose where to investigate, train, or tighten controls—not as a developer leaderboard.
What changed in GitHub Copilot usage reporting
GitHub’s July 17, 2026 changelog introduced two repository-report endpoints in the Copilot usage metrics REST API:
GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD
GET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DDEach report breaks out pull-request activity for Copilot coding agent and Copilot code review by repository. GitHub says the data includes pull requests created and merged by the coding agent, pull requests reviewed by Copilot, and review-suggestion counts separated by comment type.
That scope matters. Repository reporting is not a complete inventory of every Copilot interaction. It is specifically useful for locating agent and review activity in a codebase. Teams seeking broader adoption data—such as integrated development environment (IDE), command-line interface (CLI), chat, language, or model use—still need the wider Copilot usage metrics resources described in GitHub’s metrics overview.
The release is generally available, not a preview, as of July 17, 2026. However, the fields and access requirements remain part of an API and policy system that GitHub can update. Automations should pin the documented API version and tolerate schema additions.
Who can access repository-level reports
Access has two layers: an account policy must permit Copilot usage metrics, and the caller must have an eligible role or token permission.
For enterprise reports, GitHub identifies enterprise owners, billing managers, and authorized custom-role users with enterprise Copilot metrics access. For organization reports, organization owners and users with the relevant organization custom-role permission can retrieve the data. GitHub’s REST API reference specifies read access for Enterprise Copilot metrics or Organization Copilot metrics on fine-grained tokens, depending on the endpoint.
Classic personal access tokens and OAuth tokens use broader scopes. The current documentation lists manage_billing:copilot or read:enterprise for the enterprise report and read:org for the organization report. Prefer a fine-grained token or GitHub App with the minimum read permission required by the reporting job. Do not embed the token in a dashboard, notebook, or repository.
If a request returns 403, verify both policy and token permissions before assuming the endpoint is unavailable. A 404 can also reflect the wrong account slug or inaccessible resource. An empty or not-yet-processed day should not be interpreted as zero adoption without checking the response status and report date.
What the repository report can answer
The strongest use cases are descriptive and diagnostic. The report can help answer:
- Which repositories received Copilot code reviews on a given day?
- Where did Copilot coding agent create or merge pull requests?
- Which repositories have review activity but little agent-created pull-request activity, or the reverse?
- Where are Copilot review suggestions concentrated by comment type?
- Which repositories need a closer audit before broader rollout?
These questions can guide an administrator toward the right repository. They do not explain causation. A high count may reflect a large team, a migration, an automated queue, or repeated review cycles. A low count may be appropriate for a stable library or sensitive repository.
For teams configuring review behavior, the related GitHub Copilot code review configuration guide covers repository instructions, setup workflows, runners, and firewall boundaries. Repository activity can reveal where those controls are being exercised, but it cannot verify that the instructions produced good feedback.
A practical reporting workflow
1. Define the decision before collecting data
Start with a question that can lead to an action. Examples include selecting repositories for a Copilot review pilot, finding teams that need onboarding, or monitoring whether an approved agent rollout stays within scope.
Avoid a vague goal such as “measure AI productivity.” The endpoint does not provide enough evidence for that conclusion. If the decision concerns model or workflow quality, define labeled tasks, acceptance criteria, correction effort, failure categories, and a baseline that does not use the feature.
2. Enable policy and grant narrow access
Confirm the Copilot usage metrics policy is enabled at the appropriate account level. Assign a custom metrics-viewer role when an analyst does not need full owner or billing privileges. Use a short-lived or centrally managed credential for scheduled extraction.
Document who can see the data, where exports are stored, and how long they are retained. Repository names and activity patterns can expose internal priorities even when source code is absent.
3. Request a complete day
Call the organization or enterprise endpoint with a specific date. GitHub’s examples recommend the vendor media type and show the API version 2026-03-10:
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/orgs/ORG/copilot/metrics/reports/repos-1-day?day=2026-07-17"Use secret injection rather than replacing YOUR_TOKEN in a committed script. The API response supplies download information for a processed daily report. Validate the returned report date before loading it into a business-intelligence system.
4. Normalize by repository context
Join activity with non-Copilot context that you are authorized to use: total pull requests, active contributors, repository lifecycle, language, ownership, and risk classification. Raw counts favor larger or more active repositories.
A useful weekly view might show agent-created pull requests as a share of all pull requests, review coverage as a share of eligible pull requests, and merge rates segmented by repository type. Label those as operational ratios, not productivity scores. Do not compare teams without accounting for different workloads and policies.
5. Investigate outliers, then act
Treat an outlier as a prompt for inspection. A repository with many automated reviews may need better review instructions; one with no activity may lack enablement, have an intentional exclusion, or simply have no eligible changes.
Possible actions include improving onboarding, reviewing access policy, adding repository-specific instructions, or adjusting the pilot scope. Do not make an AI signal blocking until its false positives, missed findings, override path, and interaction with existing required checks have been measured on that repository.
Decision table: what to measure and what not to infer
| Report signal | Supported interpretation | Unsupported conclusion |
|---|---|---|
| Agent-created pull requests | Coding-agent activity occurred in the repository | The agent saved a specific amount of developer time |
| Agent-merged pull requests | Agent-created work reached a merged state | The merged code was defect-free or required no human effort |
| Pull requests reviewed by Copilot | Copilot code review was used on those pull requests | Human review was unnecessary |
| Suggestions by comment type | Review feedback composition and concentration | Suggestion accuracy, severity, or business value |
| No reported repository activity | No qualifying activity appears in that processed report | The team did not use any Copilot feature |
This distinction is the central governance rule. Activity data supports adoption and coverage reporting. Quality and impact require separate evidence such as accepted changes, defect trends, cycle time, rework, incident outcomes, and developer feedback. Even those measures need a baseline and controls for workload changes.
What this means for engineering teams
For platform and engineering leaders, repository-level visibility makes Copilot rollout less dependent on aggregate account totals. You can now map two agentic workflows—coding agent and code review—to specific repositories and focus enablement or scrutiny where the work occurs.
For small teams inside a GitHub organization, the organization endpoint is likely the practical starting point. Pull one day, confirm the schema and access model, then collect a short trend before designing a dashboard. A single day is vulnerable to release schedules, weekends, and unusually large pull requests.
For developers, this update does not change how Copilot writes or reviews code. It changes administrative observability. Teams should explain what is measured and how it will be used, especially if repository signals feed management reports. Transparent use reduces the risk that an adoption diagnostic becomes an ungrounded individual-performance score.
Verification checklist
Before relying on a repository report, confirm all of the following:
- The requested date is formatted as
YYYY-MM-DDand represents a complete processed day. - The account-level Copilot usage metrics policy is enabled.
- The caller has the correct enterprise or organization metrics read permission.
- The response and downloaded report correspond to the intended account and date.
- Repository identifiers are normalized before joining multiple days.
- Zero values are distinguished from missing, delayed, unauthorized, or ineligible data.
- Counts are contextualized with repository activity and policy, not ranked in isolation.
- Access tokens are stored outside source control and reporting outputs have an owner and retention rule.
- Any productivity, quality, or return-on-investment claim uses additional evidence and a stated methodology.
Frequently asked questions
What are GitHub Copilot repository-level usage metrics?
They are daily reports that group Copilot coding-agent and Copilot code-review pull-request activity by repository. GitHub made the two enterprise and organization endpoints generally available on July 17, 2026.
Does the report include all GitHub Copilot usage?
No. The repository report focuses on coding-agent pull requests and Copilot code-review activity. GitHub’s broader usage metrics resources cover other surfaces and breakdowns, including IDE and CLI telemetry. A repository report with no activity does not prove that nobody used Copilot chat or completions.
Can organization owners access the report?
Yes, provided the Copilot usage metrics policy is enabled. GitHub also permits authorized users with the relevant organization Copilot metrics permission. Fine-grained tokens need organization Copilot metrics read access; classic token access currently requires read:org.
Can these metrics prove that Copilot improves productivity?
No. They show activity and workflow coverage, not saved time, correctness, quality, or financial return. A credible impact study needs outcome measures, a baseline, workload context, and an explanation of confounding factors.
How often should a team collect the report?
The endpoint produces a report for one specified day, so a daily scheduled extraction is the natural collection pattern. Review trends over a longer window before acting, because weekends, release cycles, and repository size can distort a single-day comparison.