GitHub Copilot Usage Metrics API Adds Telemetry Gap and Outdated IDE Flags for Admins

If you run Copilot across an enterprise or organization, you've probably seen reports where the daily active user count looks healthy but the lines-of-code and feature breakdowns describe a much smaller group. The new fields don't fill in that missing data. They show who is affected so you know where to look.

What GitHub added​

The changelog lists four new fields: two per user and two daily counts.

Per-user fields (in enterprise and organization user reports, both 1-day and 28-day):

• client_telemetry_present: whether client telemetry arrived for that user on that day. A value of false means Copilot saw the user's activity but no usage events came from their editor.
• usage_metrics_requirements: lists each of the user's IDEs and Copilot extensions as met, unmet or unknown against the minimum supported versions.

Aggregate counts (in enterprise and organization 1-day reports, and in each day_totals entry of 28-day reports):

• missing_client_telemetry_user_count: the number of users that day whose client_telemetry_present is false.
• below_usage_metrics_minimum_user_count: the number of users that day with at least one IDE or extension below the minimum version.

You can use the counts to judge how big the problem is, then use the per-user fields to find out who needs a follow-up. GitHub says this should let admins close gaps without opening a support ticket.

In short: two daily counts give you the scale, and two per-user fields name the affected accounts and their tooling.

Why "active but invisible" users exist​

These fields fix a problem GitHub partly created by improving its own counting. In June 2026, GitHub said usage reports would draw on server-side telemetry in addition to client signals, so more of your active Copilot users show up in reports. GitHub's reasoning was blunt: network conditions, proxy configurations, client settings, and other factors can prevent a client from reporting activity, and when that happened, an active, billed user could be absent from your reports.

Counting those users fixed the headcount, but server-side signals can only confirm that someone used Copilot. They can't see what happened in the editor. GitHub's documentation still says that most metrics come from client-side IDE telemetry, and end users need telemetry enabled in their IDE for the richest data in these metrics.

That's why the changelog notes that users without client telemetry still count as active, but their reports lack detail such as lines of code, feature breakdowns and model breakdowns. GitHub's reconciliation guide adds that top-level active-user counts can be higher than the number of users in the breakdown arrays, and calls this expected behaviour rather than a data error.

Until now, though, you couldn't tell from the API which users made up that difference. The new client_telemetry_present flag answers that.

This also fits a pattern in GitHub's recent changelog posts. In late October, GitHub added a totals_by_client breakdown because tools outside the IDE often don't send editor telemetry, their usage was missing from totals_by_ide and hard to account for. The usage metrics API is gradually exposing where its own blind spots are.

In short: last summer's server-side counting got the headcount right but left the detail missing. These fields tell you who is missing it.

The likely causes​

The changelog names three common reasons a user's editor goes quiet:

1. Outdated editors or Copilot extensions that don't send the events usage metrics depend on.
2. IDE telemetry turned off. GitHub's troubleshooting material points to the telemetry.telemetryLevel setting in VS Code as one example.
3. Proxies or firewalls blocking the telemetry events. GitHub's documentation also mentions VPNs and recommends allowing the Copilot client telemetry endpoint listed in its allowlist reference.

GitHub's documentation also notes that a client that isn't a supported IDE won't send Copilot telemetry at all. That user can still count as active through server-side signals but won't appear in totals_by_ide or the detailed breakdowns.

The two signals are independent. A user can meet every version minimum and still have no telemetry, for example because they're behind a proxy. Updating someone's extension won't help if a corporate firewall is dropping their events. Check both fields separately.

How to read the numbers​

GitHub's notes include several rules that are easy to get wrong in a BI dashboard:

The last two rules matter most. If your report treats an empty field as "telemetry OK", every day before the release will look perfectly healthy, and that will be wrong.

There's also a timing issue. GitHub's reconciliation guidance says IDE telemetry is processed asynchronously, and data for a given day becomes available within two full UTC days after that day closes. If yesterday's numbers look bad, wait for the processing window to close before you start chasing proxies.

A practical workflow for admins​

Based on GitHub's changelog and documentation, here's a sensible order of operations:

1. Confirm access. The fields are available to enterprise owners, enterprise billing managers, organization owners, and anyone with a custom organization or enterprise role that grants the View Copilot Metrics permission. The Copilot usage metrics policy must also be enabled.
2. Start with the daily counts. Look at missing_client_telemetry_user_count and below_usage_metrics_minimum_user_count in 1-day reports, or in the day_totals entries of 28-day reports, to judge the scale.
3. Pull the user reports. Filter for client_telemetry_present: false and for any unmet entries in usage_metrics_requirements.
4. Handle version gaps. GitHub's supported-IDE documentation says per-user totals_by_ide entries include last_known_ide_version and last_known_plugin_version. Compare those values with GitHub's published minimums, and use device management tooling to enforce them where you can.
5. Investigate telemetry gaps separately. Check IDE telemetry settings, then check whether proxies, firewalls or VPNs are blocking the Copilot telemetry endpoint.
6. Recheck after the processing window. If a gap persists after these checks, GitHub's documentation suggests contacting its support with the affected users, IDEs, versions and dates.

Windows shops that manage VS Code and Visual Studio with Intune, Configuration Manager or similar tools can now point their update campaigns at specific named users instead of guessing.

The caveats​

These fields don't recover lost data. A flagged user's missing lines-of-code and feature detail for that day stays missing. The fields tell you who has a gap, not what they were doing.

There's also a policy question. Some organizations turn off IDE telemetry deliberately for privacy or compliance reasons. For them, a high missing_client_telemetry_user_count reflects a decision they made, not a fault. Weigh fuller Copilot reporting against those policies before telling developers to turn telemetry back on.

Finally, these signals measure how complete your metrics are, not whether users are licensed. GitHub says the Copilot user management API is the source of truth for license and seat information. Don't use telemetry flags to make seat decisions.

Bottom line: this update doesn't change what Copilot measures. It shows which users are missing from the detailed data, so admins can spend their time fixing the problem instead of trying to explain it.