GitHub Copilot Usage Metrics: What the Dashboard Proves and Misses

The production verdict

GitHub Copilot's measurement stack is worth using because it exposes adoption, code-generation activity, agent use, review flow, tool execution, latency, tokens, and errors. Its hard limit is equally important: those signals show what Copilot touched and how the workflow behaved, not whether the resulting software was better.

Treat the product as separate evidence planes:

GitHub itself calls lines-of-code data a directional measure. That is the right frame. More generated code can mean useful acceleration, unnecessary churn, or a repository that needed deletion rather than addition. Acceptance rate has the same constraint: it measures an editor action, not whether the code passed review, stayed in the branch, or survived production.

If you are still choosing the coding-agent surface, settle that boundary before instrumenting it. The production coding-agent comparison covers the control and ownership differences that telemetry cannot fix after rollout.

What GitHub added in July 2026

The July releases close a useful gap: GitHub now gives administrators a centrally enforced runtime stream and better pull-request outcome fields in the aggregate API.

On July 8, 2026, GitHub released enterprise-managed OpenTelemetry export for the Copilot Chat extension in VS Code and the agent host that powers Copilot CLI. Administrators can set an approved endpoint, transport, service name, resource attributes, headers, and content-capture policy through managed settings. A managed value overrides environment variables and user settings. GitHub's release note documents the control surface.

On July 7, 2026, GitHub added two adoption-phase fields to enterprise and organization 1-day and 28-day reports:

The avg_ prefix is easy to misread. GitHub defines both fields as medians, so do not average those medians again across teams or reporting days and call the result a company metric. Pull the underlying daily cohorts, preserve their scope, and show the sample volume beside the distribution.

The merged-only rule creates survivorship bias. A change that stalls, is abandoned, or never earns approval contributes to neither field. Pair both medians with opened, merged, closed-unmerged, and reverted pull-request counts from your delivery system. GitHub's change note states the inclusion rule explicitly.

Configure the runtime plane with content capture locked off

Start with metadata-only OpenTelemetry and make content capture an exception that needs a security review. The default already excludes prompts, responses, and tool arguments. Keep that boundary centrally enforced because enabling content capture can send source code, file contents, system prompts, tool schemas, arguments, and results to the collector.

A production managed-settings.json can begin with this shape:

{
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.example.net",
    "protocol": "otlp-http",
    "captureContent": false,
    "lockCaptureContent": true,
    "serviceName": "github-copilot",
    "resourceAttributes": {
      "rollout.cohort": "pilot",
      "engineering.unit": "platform"
    }
  }
}

The keys above map to GitHub's managed telemetry schema. Replace the example endpoint and cohort values with approved infrastructure identifiers. Keep user identity, prompt text, repository secrets, and customer data out of resource attributes. Resource attributes are for bounded operational dimensions, not a second content channel.

The trace model is useful for diagnosis. An invoke_agent span contains nested chat, execute_tool, and execute_hook work. Standard and Copilot-specific metrics expose LLM duration, token use, tool-call count and duration, end-to-end agent duration, turns, edit outcomes, and errors. Use the canonical github.copilot.* namespace for new queries where GitHub provides one. The VS Code OTel reference lists the emitted signals and attributes.

One release caveat deserves a deployment test: managed telemetry.headers are applied only to the Copilot Chat extension exporter and are not delivered to the agent host process in this release. Do not assume an authentication header that works for the extension also protects the CLI path. Verify collector authentication from each process before requiring export.

Build the adoption scorecard from the API

Use the API as a scheduled reporting input, not an alert stream. GitHub documents daily reports and a latest 28-day report under API version 2026-03-10; dashboard data may appear up to 3 full UTC days behind. Runtime alerts belong in OpenTelemetry. Adoption and workflow reviews can tolerate the aggregate delay.

The minimum extraction set is the aggregate report, per-user report, and user-team join for the same day:

set -euo pipefail

: "${GITHUB_TOKEN:?set GITHUB_TOKEN}"
: "${ENTERPRISE:?set ENTERPRISE}"
: "${DAY:?set DAY as YYYY-MM-DD}"

api="https://api.github.com/enterprises/${ENTERPRISE}/copilot/metrics/reports"
headers=(
  -H "Accept: application/vnd.github+json"
  -H "Authorization: Bearer ${GITHUB_TOKEN}"
  -H "X-GitHub-Api-Version: 2026-03-10"
)

curl -fsSL "${headers[@]}" "${api}/enterprise-1-day?day=${DAY}"
curl -fsSL "${headers[@]}" "${api}/users-1-day?day=${DAY}"
curl -fsSL "${headers[@]}" "${api}/user-teams-1-day?day=${DAY}"

Each response provides signed report download links. Store the downloaded NDJSON in a restricted analytics bucket with its report day, scope, and schema version. The documented daily enterprise history starts on October 10, 2025 and is available for up to 1 year, so long-term retention is your responsibility if the rollout needs a longer baseline. GitHub documents the report endpoints and access rules.

Build a scorecard around decisions, not whatever fields are easiest to chart:

Team metrics require a daily join between user-team membership and per-user usage; GitHub does not pre-aggregate them. Teams with fewer than 5 seated Copilot users on a day are excluded from that join report. Preserve that privacy boundary rather than reconstructing small-team behavior from other fields.

For a defensible comparison, take a full 28-day baseline before changing enablement or policy, then compare it with a matched rollout window. Match teams by repository type and work mix, annotate major releases and incidents, and keep qualitative developer feedback beside the quantitative view. The result is evidence for a rollout decision, not a causal study.

What the dashboard misses in production

The first production failure is scope mismatch. Dashboard charts do not include Copilot CLI usage, while API reports expose separate CLI fields. Copilot Chat on GitHub.com and GitHub Mobile are also outside the usage-metrics dataset. A dashboard can therefore show flat adoption while a team moves significant work into a surface it does not chart.

The second failure is partial client telemetry. The dashboard is primarily fed by IDE telemetry and supplemented by server-side signals. A user found only through server-side data can count as active while feature and lines-of-code breakdowns remain empty. Monitor missing dimensions as a data-quality signal; do not treat an empty breakdown as zero usage.

The third failure is sensitive or expensive telemetry. Repository, branch, commit, model, tool, token, and duration attributes are useful, but unbounded branch names and per-commit views can create high-cardinality storage. Transform identifiers at the collector, apply explicit retention, and reserve raw traces for a narrow operational window. Keep content capture locked off unless a documented incident workflow requires it.

The fourth failure is measurement gaming. A rollout score tied to prompt count, accepted code, or lines changed encourages more activity rather than better engineering. The safer review asks whether developers can finish suitable tasks with fewer blocked runs, whether review flow holds, whether quality gates stay green, and whether the tool remains useful in developer feedback.

Who should use this stack

Use the combined stack when an engineering organization has a real Copilot rollout owner, an approved OTLP collector, enough team size for cohort reporting, and access to delivery and quality data. It is especially useful when VS Code agents and Copilot CLI are moving from opt-in experiments to a governed team workflow.

Do not build this pipeline for an individual seat or a tiny trial that cannot support privacy-safe cohorts. Do not use it if the organization has not defined which tasks are appropriate for agents, which tools require approval, what quality gates cannot be bypassed, and who owns failed runs. Telemetry cannot repair a missing operating policy.

GitHub currently lists Copilot Business at $19 USD per granted seat per month and Copilot Enterprise at $39 USD per granted seat per month. Budget the observability backend, secure storage, data transformation, and review ownership separately. The seat-mix and rollout-cost model is reusable even when the vendor changes.

The production rule is simple: expand only when adoption is healthy, runtime failures are understood, review flow is stable or improving, and quality does not regress. If those signals disagree, hold the rollout and investigate the disagreement. More telemetry is useful only when it changes a decision.

Frequently asked questions