GitHub's Copilot metrics now report which skills, MCP servers and slash commands get used

An organization that has spent a year writing Copilot skills and wiring up MCP servers has had no way to see which of them anyone actually reaches for. GitHub closed that gap on September 17, 2026 with two changes: the usage metrics API now names the customizations in use, and the impact dashboard now reports engagement per feature rather than activity in aggregate.

What is now counted

The new fields appear in enterprise and organization reports: per-user and aggregate one-day reports, per-user 28-day reports, and the daily totals inside aggregate 28-day reports. Each report answers two questions. totals_by_skill, totals_by_custom_agent, totals_by_mcp, totals_by_slash_cmd and totals_by_plugin list the five most active items with an interaction_count on each. The matching distinct_*_use_count fields report how many different items were used at all, including those below the top five.

What an interaction means depends on the category, and the difference matters. For skills, slash commands and plugin skills it counts invocations. For custom agents it counts starts. For MCP servers it counts connection attempts only — successful and failed alike — so calling ten tools over one established connection still registers as one.

• The distinct counts are the ones to watch over time, because a rising number means the variety of customizations in use is growing.
• In an aggregate report each item counts once for the whole organization, not once per user.
• Names of GitHub-provided items are shown; customer-defined ones are grouped under a generic label instead.
• Empty arrays and zeroes mean no matching activity, while null or absent fields mean the data was unavailable.

The one arithmetic trap

Plugin metrics count only the skill invocations that belong to a plugin. Every plugin interaction therefore also appears in the skill totals, which makes the plugin figures a subset rather than a separate category. Adding the two together double-counts, and GitHub says so explicitly in the notes.

The privacy rule has a similar shape. Because customer-defined names are withheld, a team that writes all its own skills will see a large total under a generic label and almost nothing named. That is a reporting limit, not a measurement failure, and a dashboard built on top of these numbers should say which is which.

The impact dashboard counts people, not calls

The second change reports engagement: how many active users touched a given feature on at least two days during the 28-day period. A single curious afternoon therefore does not register, which is the point — the question being answered is whether a feature became part of a routine.

The breakdown covers code completion, agent edits, passive and active Copilot code review, the Copilot cloud agent, Copilot CLI and the Copilot app. A person can appear under more than one feature. Alongside it, users_in_phase_28d now reports the full rolling 28-day population in each AI adoption phase, while the older engaged-user field continues to count only those active on the day itself.

• Feature engagement appears only in 28-day aggregate reports, not in user-level ones.
• Active code review means a person requested a review or applied a suggestion; passive means Copilot was assigned automatically and the person did nothing with it.
• Reports require the Copilot usage metrics policy to be enabled and are limited to enterprise owners, billing managers, organization owners and roles granted the metrics permission.