Repository-Level Copilot Metrics Need a Cardinality Budget Before Export

Repository-Level Copilot Metrics Need a Cardinality Budget Before Export

Primary source: https://github.blog/changelog/2026-07-17-repository-level-github-copilot-usage-metrics-generally-available/. GitHub made repository-level Copilot usage metrics generally available on July 17. Repository granularity helps allocation, but naïvely exporting every repository, team, model, editor, and date combination can create high-cardinality telemetry. GitHub usage API -> bounded collector -> normalized warehouse table -> dashboard Enter fullscreen mode Exit fullscreen mode Start with a field budget: Field Policy repository stable ID; name in restricted dimension table date daily partition model/editor documented bounded enum user aggregate or pseudonymize unknown labels quarantine before dashboard Track fetched rows, API errors, late data, unknown repositories, cardinality per field, and dashboard freshness. Backfill one day at a time with an idempotency key (repo_id, date, metric). Inject a renamed repository, deleted repository, duplicated page, and API timeout. Rollback pauses ingestion without deleting the last known-good partition. This plan does not describe GitHub's exact payload or guarantee metric completeness; verify the current API schema and privacy requirements. At what repository count would your current dashboard design become an operational liability?

Original Source

Read the full article at Dev →

KhanList aggregates and links to publicly available news content. We do not host full articles from third-party sources. Always verify important information with original sources.