A falling agent-usage chart is a reason to investigate—not a reason to conclude that developers stopped using Copilot. First identify the missing measurement, its reporting period and the client that should have produced it. Otherwise, a reporting gap can become a misleading adoption report.
Evidence and scope: Official GitHub sources were checked on 7 October 2026. CoreSecTech did not independently reproduce the reporting defect or test an organization’s dashboard. No organization data, API responses or measured recovery results are presented. The diagnostic sequence below is CoreSecTech’s recommended investigation workflow; incident statements are attributed to GitHub.
1. Recognize the symptom before choosing a fix
Describe the discrepancy in one sentence: which report, which metric, which users and which dates? “Copilot metrics are missing” is too broad. Preserve the original export and record when it was downloaded before refreshing or changing anything. A later result should not erase the evidence you started with.
| Observation | Possible explanation | What to check next |
|---|---|---|
| Recent day appears empty | Processing may be unfinished | Check the report’s covered day and the documented processing window. |
| Active users remain visible but detail is sparse | Incomplete client telemetry is possible | Identify the relevant client and confirm telemetry policy. |
| API contains a metric absent from a chart | The views may cover different surfaces | Read that field’s definition and dashboard coverage. |
| Old and new exports disagree | Different extraction times or filters are possible | Align scope, dates, filters and export time. |
| A drop persists after those checks | An actual usage change remains possible | Discuss the workload with the affected team; do not infer a cause from the chart alone. |
On narrow screens, swipe tables horizontally if needed. These explanations are hypotheses, not a diagnosis of your organization.
2. Identify exactly what is missing
Write down the chart label or API field—not just “agent.” Separate a missing report, an omitted optional field, an empty breakdown and a recorded zero. Check the schema before treating them as equivalent. Ask whether the expected activity actually belongs in that report.
| Metric/source | What it tells you | What it does NOT prove |
|---|---|---|
| Active-user count | Recorded participation under that metric’s definition | Complete activity detail or developer productivity. |
| IDE lines added/deleted | Recorded editor changes | Code quality, delivered business value or faster development. |
| CLI request count | Requests, including automated follow-ups | Number of human prompts or unique users. |
| Licence/seat record | Assigned access | Actual use or an invoice total. |
| NDJSON export | A report snapshot for analysis | An independent measurement that repairs missing telemetry. |
Use GitHub’s field reference to define each unit, and its metrics overview to distinguish usage from seat management. Do not invent a “healthy usage” threshold.
3. Align the reporting date and population
Choose one period and one population for the investigation. Record the enterprise or organization, report type, date range, filters and metric unit. Compare equivalent views before comparing totals. Keep calendar-month, rolling-window and daily measurements separate.
Organization totals cannot simply be added to reproduce an enterprise total: users can belong to several organizations, while enterprise counts deduplicate them. GitHub also distinguishes daily API cohort populations from the impact dashboard’s trailing-window population. See attribution rules and reconciliation guidance.
For an internal report, label a comparison “not aligned” until the populations match. That is more informative than forcing the numbers to agree with an undocumented adjustment.
4. Allow for processing—and disclose the documentation difference
The current official pages give different timing guidance. The overview says data becomes available within two full UTC days after the covered day closes. The reconciliation guide says recent telemetry typically finalizes within three full UTC days and recommends re-exporting after that window.
Treat availability and finalization as separate checkpoints; do not promise a universal two-day guarantee. CoreSecTech recommends checking again after the longer documented window before escalating a recent-day gap. Record the UTC day rather than counting 48 hours from an individual prompt. This recommendation is not a new GitHub service-level commitment.
If a later export changes, record the revision; it is consistent with delayed or revised reporting, not proof of the underlying cause. If it does not, continue investigating. Waiting cannot reconstruct activity that was never attributable.
5. Identify the Copilot surface
In GitHub’s current schema, used_agent means IDE agent mode, used_cli means Copilot CLI, and used_copilot_cloud_agent identifies cloud-agent use. Code-review indicators are separate. Dedicated VS Code Agents-window fields are also distinct from editor-window agent mode.
Do not transfer expectations from one surface to another. Individual agent-app metrics are available in APIs/NDJSON but not usage dashboards. The standard usage charts exclude CLI activity; CLI has its own fields. Check the surface-specific definitions before building a combined total.
Ask the developer which application and interaction produced the expected event. An editor session, a command-line session and a pull-request review are not interchangeable observations. If that answer is unknown, mark the case incomplete rather than blaming an IDE incident.
6. Check client versions against the correct requirement
GitHub’s 6 October disclosure says SDK-based IDE agent sessions lacked IDE identification, excluding most activity and misattributing some to CLI. Agent interactions and agent_edit lines were undercounted in 1-day and 28-day enterprise, organization and user reports. Earlier non-SDK versions were not affected. GitHub did not provide a complete affected-version range.
| Client | Incident fix listed on 7 October | Status in the disclosure |
|---|---|---|
| VS Code | 1.139.0 or later | Available |
| Visual Studio | 18.12 | Expected October; not released |
| JetBrains | Next plugin release; no number supplied | Expected late October |
| Eclipse / Xcode | Next plugin releases; no numbers supplied | Expected by November |
The general supported-client table still lists VS Code 1.107.1 with Copilot Chat 0.35.3. Those are general minimum requirements—not the incident fix. The two tables answer different questions. Recheck official release information before deploying updates.
Record the installed IDE and extension versions through your approved inventory process. Where available, per-user totals_by_ide contains last-known version objects and sampling timestamps. Compare the sample time with the actual installed version; a previous observation is not a live inventory. See the version-field definitions.
7. Inspect telemetry without weakening controls
Server-side signals can retain active-user visibility when client telemetry is absent, while detailed feature and lines-of-code data remain incomplete. A nonzero active-user total therefore does not establish complete editor reporting. GitHub describes this in its telemetry overview.
Have the responsible administrator review IDE telemetry policy and approved network handling. Do not disable a firewall, proxy, endpoint protection or privacy policy to make a chart populate. If a policy intentionally restricts telemetry, document that measurement limitation and obtain proper approval before proposing a change.
Use one authorized, narrow investigation at a time. Record what was inspected, what was changed, who approved it and when. Do not send source code, access tokens or private report files to public forums. This article requires no new token or security-policy change.
8. Compare dashboards, APIs and exports correctly
These views share underlying telemetry; an export is not an independent confirmation of collection. Export timing, report shape and presentation can produce differences. GitHub’s reconciliation guide also notes that Unknown categories appear in API/NDJSON but are excluded from dashboard visualizations.
Start with the existing report download, if authorized. Match the covered period rather than its download date. For API retrieval, the REST reference documents policy/permission requirements and time-limited signed download links. A retrieval or authorization failure is not a zero-usage result. Preserve the status/error privately and investigate access separately.
For a reproducible comparison, keep an evidence record containing: report name, scope, covered dates, extraction time, filters, field definition and observed discrepancy. Retrieve the same period again after processing. Record differences without substituting made-up example values or normalizing away the unexplained gap.
9. Separate historical loss from future recovery
For the October defect, GitHub says missing attribution cannot be backfilled; historical CLI misattribution cannot be corrected. Billing was unaffected, and CLI users do not need to update for this IDE issue. These limits apply to that incident, not every missing report. See the incident explanation.
Annotate affected reporting periods instead of drawing a continuous adoption trend through them. After an approved client update, evaluate later fully processed periods; do not promise an immediate jump. Keep rollout dates alongside your reports so a reporting change is not credited as a productivity improvement.
10. Decide what the numbers actually support
If coverage, dates and client conditions align and a decline remains, an actual change in usage is still possible. Ask about workload, leave, team membership and tool choice before selecting an explanation. Record corroborating information separately from telemetry. An unresolved discrepancy should remain unresolved in the management report.
GitHub’s interpretation guidance provides adoption and engagement context. CoreSecTech’s safeguard is stricter: usage, accepted output and pull-request associations are not direct proof of developer productivity. Correlation does not establish that Copilot caused an output change. Do not rank individual developers by a missing or incomplete metric.
11. Verification checklist
- The exact metric, unit and expected surface are identified.
- Scope, population, dates and filters match across comparisons.
- The covered UTC day has passed the documented processing checkpoints.
- Installed versions are recorded; general support and incident-fix requirements are separate.
- Telemetry and network policy were inspected through authorized channels.
- A later export was compared without overwriting the original evidence.
- Historical gaps and rollout dates are annotated, not silently repaired.
- The conclusion states what is confirmed, uncertain and outside the metric’s scope.
If the discrepancy remains, prepare a minimal support case: affected report/field, covered dates, client versions, retrieval time, exact error if any and steps already checked. Redact user identifiers and confidential material. Ask GitHub Support to confirm expected reporting behavior rather than asserting a defect you have not reproduced.
Frequently asked questions
Does missing agent usage mean developers stopped using Copilot?
No. Establish report coverage, processing status and telemetry completeness first. A genuine reduction remains possible, but a missing measurement alone cannot establish it.
Is every missing metric caused by the October 2026 issue?
No. Client identification, disabled or blocked telemetry, reporting delay and mismatched views are different hypotheses. Follow the diagnostic sequence instead of applying one incident explanation to all surfaces.
Will updating an IDE repair previous reports?
Not for the attribution loss GitHub disclosed in October. Preserve an annotation for that gap and assess later reporting separately. Do not assume the same limitation applies to an unrelated delay.
Can API data prove that the dashboard is wrong?
Not by itself. First align the field definition, surface, population and dates. The views may expose different detail or reflect different extraction times.
Can these metrics demonstrate productivity gains?
No single usage metric establishes that. Evaluate outcomes and quality with appropriate contextual evidence; do not present association as causation.
Conclusion: validate the measurement before the conclusion
Start with the metric and reporting period, identify the surface, check collection conditions and compare like-for-like evidence. Keep historical limitations visible. The useful outcome is a defensible explanation—or an honestly documented open question—not a graph made to look complete.