GitHub Copilot usage reports can now show activity per repository, closing a practical gap for organizations that could see overall adoption but not where coding-agent and code-review work occurred.
The new reports are useful for rollout decisions: they can show which repositories have pull requests created or merged by Copilot coding agent and which receive Copilot code reviews. They are not a productivity score, a quality measurement, or proof that Copilot caused a pull request to succeed.
That distinction should shape the implementation. Use the data to find repositories worth investigating, then join it with delivery and quality signals you already trust. Product details below were checked against GitHub’s changelog and API documentation on 2026-07-20.
What GitHub released
On July 17, GitHub made two repository-report endpoints generally available:
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-DDThe release announcement says the daily reports cover two product areas:
- Pull requests created and merged by Copilot coding agent.
- Pull requests reviewed by Copilot code review, including suggestion counts broken down by comment type.
Each report contains one entry per repository with activity on the requested day. Repositories with no covered activity are absent, so a missing row is not the same thing as a row of zeroes. The API response provides temporary signed download links for the report files rather than embedding the full dataset in the first response.
Access is deliberately limited
The feature is intended for organization and enterprise reporting, not public repository analytics. GitHub’s REST API documentation lists these access paths:
- At enterprise scope, owners, billing managers, and authorized users with the fine-grained
View Enterprise Copilot Metricspermission can retrieve reports. - At organization scope, organization owners and authorized users with
View Organization Copilot Metricscan retrieve them. - The Copilot usage metrics policy must be enabled.
For a fine-grained token, request the corresponding Copilot metrics permission with read access. Classic personal access tokens and OAuth tokens use the documented enterprise or organization scopes. Keep the credential out of scripts and logs; pass it through the normal secret mechanism for the environment running the collection job.
GitHub’s current examples send the X-GitHub-Api-Version: 2026-03-10 header. Pinning the API version makes the integration easier to test than silently accepting a future default.
What the report can answer
Repository-level attribution supports questions that an organization-wide total cannot:
- Where is agent work happening? Compare repositories with coding-agent pull request activity against the set where Copilot is enabled.
- Where is code review being used? Identify repositories that receive AI reviews and the types of suggestions recorded.
- Where should enablement start? A repository with relevant work but little covered activity may need configuration, training, or a workflow change.
- Where should a pilot be examined more closely? A sudden rise in AI-created or AI-reviewed pull requests is a prompt to inspect cycle time, rework, defects, and developer feedback.
The endpoint gives a location for activity. It does not explain why usage is high or low, whether suggestions were correct, or whether the work saved time.
What it does not measure
Do not turn activity counts into claims the source cannot support.
A created pull request is not delivered value. It may be closed, rewritten, or merged after substantial human work. A merged pull request is stronger evidence of workflow completion, but it still says nothing by itself about quality or time saved.
A review suggestion is not a prevented defect. Counted comments can be useful, noisy, correct, or ignored. Sample the underlying reviews and measure acceptance, rework, or confirmed findings before judging effectiveness.
Repository reports are not seat reports. GitHub says license and seat management data comes from the separate Copilot user management API. Use that source when the question is assignment, utilization, or unused licenses.
The wider metrics system has coverage limits. GitHub’s Copilot metrics overview says some usage depends on client telemetry, while server-side signals can fill parts of the active-user count. Detailed breakdowns can remain empty when richer telemetry is unavailable. The documentation also excludes GitHub.com Chat and GitHub Mobile activity from the general usage dataset.
Data is not real time. GitHub says dashboard and API reports should be available within two full UTC days after the measured day closes. Build reporting around that delay instead of flagging the latest date as missing.
A safer evaluation design
Start with a four-week baseline for each participating repository, then compare like with like. A small documentation repository and a high-volume service should not share one target.
Track the Copilot report beside a few existing engineering measures:
- Pull request lead time and review wait time.
- Reopen, revert, or follow-up fix rates.
- CI failure rate before merge.
- Review-comment resolution and sampled suggestion quality.
- Short developer feedback on whether the agent reduced or added work.
Look for a consistent pattern, not a single favorable week. If AI-reviewed pull requests rise while review time falls but follow-up fixes also rise, the result is mixed. If activity is low, investigate access and workflow fit before concluding that the tool has no value.
Avoid individual rankings. Repository context, task mix, telemetry coverage, and team practices can dominate raw counts. The data is better suited to finding workflow questions than scoring developers.
A minimal collection workflow
For each complete reporting day, request the organization or enterprise endpoint, download every returned file before its signed URL expires, and store the raw report with its date. Treat a 204 No Content response as a state to record, not an automatic retry storm. Validate the schema before loading rows into a dashboard.
Keep raw activity separate from interpretations. A durable table can hold repository, report date, coding-agent pull request counts, and code-review counts. A second layer can join delivery metrics and document calculated rates. That separation makes it possible to correct an analysis without rewriting the source record.
The useful conclusion
Repository-level Copilot metrics make adoption visible at the unit where engineering work is organized. That is a meaningful improvement over a single organization total. The reports still measure activity, not business impact.
Use them as a map: locate active and inactive repositories, choose a small set for deeper review, and compare the activity with quality, speed, and developer experience. The API can tell you where to ask the next question. It cannot answer that question on its own.
Next steps: Define pass/fail evidence with the machine-gate pillar, inspect changes with the AI-generated code review method, collect bounded unattended evidence through a scheduled agent run, and interpret the measures within the team coding-agent adoption guide.
Editorial record: Written by the Context Wire editorial desk. Method: a two-layer collection design separating raw activity from delivery, quality, and experience measures. Structure and source inventory reviewed 2026-08-23; GitHub fields and access rules retain their in-text verification date. Advertising may appear on this site. This article contains no affiliate links.