GitHub Copilot Impact Dashboard: A Practical Guide

GitHub released the Copilot impact dashboard on July 22, 2026, for enterprise administrators and organization owners with access to Copilot usage metrics. It groups engaged users into three AI adoption phases, separates licensed but unengaged users, and connects each cohort with pull-request throughput and speed indicators. The practical consequence is a faster way for engineering leaders to see whether Copilot use is moving from code suggestions toward agents. However, the dashboard shows associations in GitHub telemetry, not proof that Copilot caused higher productivity. Use it to identify questions and enablement opportunities, then validate any impact claim with team context, quality measures, and a suitable baseline.

Key takeaways

The dashboard became available on July 22, 2026, and requires access to GitHub Copilot usage metrics.
Users are classified as Passive or into Phase 1 (Code-first), Phase 2 (Agent-first), or Phase 3 (Multi-agent or Copilot app) based on product use over a rolling 28-day window.
Cohort cards combine adoption counts with pull requests merged, median merge velocity, and lines of code per user.
Six-month trends can show cohort movement and pull-request patterns, but they cannot establish causation on their own.
The safest use is to target onboarding, workflow support, and further investigation—not rank individual developers or claim return on investment.

What changed in the GitHub Copilot impact dashboard

GitHub’s July 22 announcement adds a visual impact view to its existing Copilot usage-metrics system. Previously, administrators could use account dashboards, exports, and application programming interfaces (APIs) to inspect activity. The new view organizes some of that evidence around adoption depth rather than presenting only active-user totals.

The dashboard now contains five main elements:

Dashboard element	What GitHub displays	Appropriate use
Adoption cohorts	Passive plus three phases of engaged use	Understand which Copilot workflows are being used
Adoption multiplier	Passive-cohort results compared with the average of engaged cohorts	Form a question about differences that need validation
Six-month trends	Cohort growth and pull-request throughput over time	Look for sustained changes rather than a one-day spike
Recommended next steps	GitHub guidance for deeper adoption	Select enablement experiments, subject to team needs
Potential return on investment	Estimated Copilot cost per developer, payroll share, and pull requests per month for early-phase versus agent-first groups, with a salary selector	Model a directional hypothesis; do not treat estimated costs or payroll input as realized ROI

This dashboard does not replace the repository-level reports covered in our Copilot repository usage metrics guide. The repository report locates coding-agent and code-review activity in particular repositories. The impact dashboard instead gives eligible administrators a cohort-oriented view across users and connects those cohorts with pull-request indicators.

Who can access the dashboard

GitHub’s August 7 dashboard update lists enterprise owners and billing managers, organization owners, and users with a custom organization or enterprise role granting View Copilot Metrics. The Copilot usage metrics policy must be enabled.

GitHub documents the navigation path as:

Open the relevant enterprise on GitHub.com.
Select Insights.
Select Copilot impact in the sidebar.

The dashboard is available at both enterprise and organization level. Access depends on the current role and the enabled Copilot usage metrics policy; an ordinary Copilot seat alone is not listed as sufficient.

If the menu is missing, verify the account context, the Copilot usage metrics policy, and the viewer’s role. The release does not state that individual Copilot subscribers receive this enterprise impact view.

How the adoption phases work

GitHub says cohort assignment uses the ai_adoption_phase classification from the Copilot usage metrics API. Classification is based on Copilot product activity over a rolling 28-day window. This is a behavioral grouping, not a skill rating or job-performance grade.

Passive: licensed but not engaged

The Passive segment contains licensed users who are not engaged under the dashboard’s classification. A passive label does not explain why. The user may be newly licensed, on leave, working outside measured workflows, blocked by setup, or intentionally avoiding Copilot for a sensitive project.

Treat this cohort as an investigation queue. Check license age, team policy, role, supported editor setup, and current workload before sending reminders or reclaiming a seat. Training should follow an identified need rather than a dashboard label alone.

Phase 1: Code-first

Phase 1 represents code-first adoption. In practical terms, this is the cohort to examine when users engage with core coding assistance but have not moved into the agent-oriented patterns represented by later phases.

Code-first use can be entirely appropriate. A team maintaining a stable library may benefit from completions and chat without delegating pull-request work to agents. Do not define progression to a higher phase as an automatic goal; match the workflow to repository risk, task repeatability, and review capacity.

Phase 2: Agent-first

Phase 2 represents agent-first use. This signals deeper use of agentic workflows, but the phase name does not establish autonomy level, task complexity, or output quality. An agent can produce more pull requests while also creating more review work.

Teams in this cohort should verify their review and repository controls. The Copilot code review configuration guide explains instruction files, runtime setup, runner selection, and firewall boundaries introduced in GitHub’s July controls update.

Phase 3: Multi-agent or Copilot app

Phase 3 covers multi-agent or Copilot app adoption. It is the deepest phase in the dashboard’s current classification, not a certification of maturity. Multiple agents may increase concurrency and coordination costs as well as output.

Before encouraging this pattern broadly, define task ownership, approval points, credential boundaries, and a way to detect duplicated or conflicting work. GitHub’s classification describes Copilot telemetry; it does not establish that multi-agent execution is safe, efficient, or appropriate for a particular repository.

How to interpret the dashboard metrics

Each adoption card shows the number and share of users in the cohort, average pull requests merged per user per month, median pull-request merge velocity, and average lines of code per day per user. GitHub also provides trends covering six months.

Count and share answer an adoption question: how many measured users fall into each phase? They do not answer whether the organization has the right licenses, whether users are satisfied, or whether their work improved.

Watch the denominator. Changes in seat assignment, reorganizations, leave, acquisitions, or policy eligibility can move cohort shares even when individual behavior is stable. Annotate these events before interpreting a trend.

Pull requests merged per user

Average pull requests merged per user per month is a throughput indicator. It can rise because work is split into smaller changes, more repositories adopt pull-request workflows, or teams handle a different mix of tasks. More merged pull requests are not inherently better.

Pair this measure with change size, rework, rollback or incident data, review participation, and repository type. Avoid comparing a documentation team, a platform migration, and a safety-critical service as though their pull requests were interchangeable.

Median pull-request merge velocity

Median merge velocity describes the middle of the observed distribution and is less sensitive to extreme cases than an average. It still reflects the entire delivery system: review availability, continuous integration duration, branch policy, change complexity, time zones, and release practices can all affect it.

A faster median can be useful when quality and control measures remain acceptable. It should not be interpreted as time saved by Copilot without a design that separates Copilot’s influence from other changes.

Lines of code per day per user

Lines of code (LoC) measure output volume, not value. Generated, suggested, or changed lines vary dramatically by language, formatting, refactoring style, and task. Deleting code may be the best outcome; generated tests may add many valuable lines; boilerplate may add volume without equivalent value.

Use this metric directionally and within comparable contexts. A useful evaluation separates task success, quality, cost, latency, and human review instead of compressing them into one count.

What this means for engineering leaders

The dashboard makes adoption depth easier to discuss, but its most defensible output is a prioritized set of questions. A growing Phase 2 cohort may justify agent-specific office hours. A persistent Passive cohort may prompt a license or access review. A Phase 3 increase may trigger a review of agent coordination and governance.

Editorial inference: the dashboard is better suited to enablement and portfolio-level observation than to individual performance management. GitHub connects cohort behavior with pull-request outcomes, but the official release does not claim a controlled causal study. The adoption multiplier is a comparison between cohorts, and those cohorts may differ in role, workload, experience, repository access, and willingness to adopt new tools.

Use the view as one layer in a decision process:

Identify a sustained cohort or throughput pattern.
Check whether licensing, policy, team composition, or workload changed.
Inspect comparable repositories or teams rather than global totals alone.
Ask developers and reviewers what changed in their workflow.
Run a limited enablement or governance intervention.
Evaluate quality, delivery, and human-effort measures together.

Decision criteria for acting on a signal

Act when the signal is sustained, the affected cohort is large enough to matter operationally, and the team can name a reversible intervention. Examples include fixing editor setup, clarifying approved agent use, improving review instructions, or reclaiming genuinely unused seats.

Pause when a result depends on a small cohort, a reorganization, an unusual release cycle, or incomparable teams. Do not use the adoption multiplier alone to approve a procurement expansion, calculate return on investment, or set an individual target. Those decisions require cost data, outcome definitions, a credible baseline, and controls for other factors.

Verification checklist

Before presenting Copilot impact dashboard findings, confirm:

The dashboard is being viewed in the intended enterprise or organization context.
The Copilot usage metrics policy is enabled and the viewer has an eligible role.
Cohorts are understood as rolling 28-day behavioral classifications.
Seat additions, removals, leave, reorganizations, and policy changes are annotated.
Six-month trends are preferred over isolated points when making rollout decisions.
Pull-request measures are segmented by comparable team or repository context.
Lines of code are not treated as a standalone quality or productivity measure.
Passive users are investigated before licenses are removed or training is mandated.
Any causal or financial claim uses evidence beyond the dashboard.
Individual data is handled under a transparent, documented governance policy.

Frequently asked questions

What is the GitHub Copilot impact dashboard?

It is an administrative dashboard released on July 22, 2026, that groups Copilot users by adoption phase and displays cohort-level pull-request and code-output indicators, trends, and suggested next steps.

Who can see the Copilot impact dashboard?

GitHub lists enterprise owners and billing managers, organization owners, and users with a custom organization or enterprise role granting View Copilot Metrics. The Copilot usage metrics policy must be enabled.

What are the three GitHub Copilot adoption phases?

GitHub labels them Phase 1 (Code-first), Phase 2 (Agent-first), and Phase 3 (Multi-agent or Copilot app). A separate Passive segment covers licensed but unengaged users. Assignment uses product activity over a rolling 28-day period.

Does the adoption multiplier prove that Copilot improves productivity?

No. It compares the passive cohort with the average of engaged Copilot users. The cohorts are not necessarily equivalent, so the comparison can support investigation but does not by itself show that Copilot caused a throughput difference.

Does the dashboard replace the Copilot usage metrics API?

No. The dashboard provides a visual cohort view. GitHub continues to document APIs and raw team-level newline-delimited JSON (NDJSON) data for custom reporting, while repository-level reports answer a different question about where agent and review activity occurs.