Copilot Metrics Viewer: reading your organisation's Copilot usage

The v3 rewrite changed the shape of the problem

The most important line in the documentation is a breaking change, not a feature. As of v3.0, the application uses the Copilot Usage Metrics API for all data, and the legacy Copilot Metrics API was shut down on April 2, 2026 and is no longer available. That closure reshaped the tool. The new version uses the async usage metrics API for everything, added a historical mode with PostgreSQL for data beyond the 28-day rolling window, added a per-user metrics tab with individual usage breakdowns, and changed team metrics so they are derived from per-user data rather than read from the deprecated team-level endpoints. A sync service handles automated daily data collection. In other words, what used to be a straightforward API call is now a data pipeline, and that is the single thing to understand before choosing a deployment.

Two operating modes, and only one of them has teams

The application supports two operating modes, and the difference is not cosmetic. In Direct API mode it fetches metrics from GitHub's API on each page load, needs only a GitHub token, and returns the latest 28-day rolling window. Team metrics are not available in this mode, because team metrics are derived from per-user records stored in the database. In Historical mode it reads from a local PostgreSQL database that is synced daily, which needs the database plus the sync service, gives full history with no retention limit, and enables team metrics derived from stored per-user data filtered by team membership. The documentation for each mode is in DEPLOYMENT.md. The practical summary is that the simplest setup is also the one with the fewest views, and that per-user time-series history and team comparison both live behind the database.

Team metrics are computed, not fetched

Since GitHub's Copilot Usage Metrics API does not provide team-level endpoints, the project derives them. The stated method is to fetch per-user daily metrics from the organization or enterprise endpoint, resolve team membership through the GitHub Teams API, and aggregate the per-user data in memory. The project says this works in both Direct API mode, with its 28-day window, and in Historical mode, with the full history. In the Teams tab you select one team for a deep dive with KPI tiles, time-series charts for acceptance rate, active users, feature usage and model usage, language and editor breakdowns, and a per-user activity table, or you select two or more teams to compare them side by side. The in-memory aggregation is worth noting for anyone with many users: the cost of a team view scales with the size of the organisation, not the size of the team.

Scoping the whole dashboard to a team with a URL

A team can be baked into the link, so that every tab, including IDE metrics, chat, agents and languages, filters to that team's members only, with a blue banner at the top of the page confirming the active scope and offering a quick link back to the organisation view. The URL patterns are two lines.

https://<your-host>/orgs/<org>/teams/<team>
https://<your-host>/enterprises/<enterprise>/teams/<team>

The examples in the documentation make the shape concrete, with local paths for an organisation team and an enterprise team, and a third path that adds a query parameter to serve mock data instead. The mock data path is not just for demos, because the whole application can run on mocked data with no GitHub token at all, which is how the end-to-end tests exercise the interface without touching a real organisation.

Per-user metrics, credits and the My Usage tab

The per-user metrics tab shows individual usage including code completions, chat interactions and code review activity, with summary tiles for total users, active users and average acceptance rate. In Historical mode that tab also shows per-user time-series history charts, so you can track one person's adoption over time rather than only a snapshot. The per-user table carries an AI Credits column showing each user's premium-request spend, sourced from the ai_credits_used field that GitHub added to the users-28-day report on 2026-06-19, and the column shows a dash when GitHub has not reported credits for the period, which happens with older mock data or with enterprises that have not enabled premium-request billing. Separately, the My Usage tab is a personal dashboard for the currently authenticated user, showing your own active days, interactions, accepted lines, AI credits used, top IDE and top model, filtered server-side by the session user login so you cannot see another user's data from it. It appears when an auth provider is configured and is hidden in PAT-only mode, where there is no session user to filter by.

Running it with Docker, in three shapes

The repository ships a compose file and a Dockerfile, and the compose file documents the three shapes you can run. With mock data and no GitHub token, you start the web service and open the organisation page with a query parameter. With real data in Direct API mode you export a token, the organisation name, and a flag that turns off the mocked data setting. With the database you also start the db service, and the compose file notes that historical mode is enabled simply by setting DATABASE_URL, with no separate flag needed, so the first request auto-syncs from the API to the database and later requests read from the database. A one-time population run is a separate sync service invocation. The compose file also documents the testing path, running the Playwright end-to-end tests in mock mode across three browsers, and a full storage pipeline test that seeds the database with mock data first. The Dockerfile is a two stage build on node:24-alpine, exposing port 80 through the NITRO_PORT variable for backwards compatibility.

The stack behind the dashboard

The application is a Nuxt project, and the package manifest shows the shape of it. Nuxt is the framework, Vue and Vuetify are the UI layer, and vue-chartjs with chart.js draw the charts. nuxt-auth-utils handles sessions, and @azure/msal-browser is present for the Microsoft identity provider. The data side uses pg for PostgreSQL, and date-holidays is a dependency, which connects to the date range filter that can exclude weekends and holidays from the calculations. The scripts section is the standard Nuxt set, build, dev, generate and preview, plus typecheck through nuxt typecheck, lint through eslint, unit tests through vitest and end-to-end tests through Playwright. There is a separate tsconfig.sync.json and a Dockerfile.sync for the sync service, so the sync job is a separate buildable unit rather than a mode of the web app. Deployment options are broad, with an azure-deploy directory, an azure.yaml, a k8s directory, a Dockerfile and a devcontainer.

Dates, releases and where this project stands

The release history shows a project shipping fast, with v3.11.3 on 2026-07-09, v3.11.2 on 2026-07-08 and v3.11.1 on 2026-07-01, so several patch versions within days, while the manifest is already at version 3.11.4. The last push to the repository was on 2026-08-12, and the project is not archived. The rest of the repository is telling about the kind of project this is. There is a CODEOWNERS.md, a CODE_OF_CONDUCT.md, a SECURITY.md, a SUPPORT.md, a MARKETPLACE.md, a TRANSPARENCY_DISCLOSALS.md and a CONTRIBUTING.md, which is a lot of governance files for a dashboard, and they are placed there because this tool holds an organisation-wide view of who is using what. The licence is MIT, and a hosted instance is linked from the repository for people who want to look before deploying.

Editorial conclusion

Copilot Metrics Viewer fits an organisation administrator who needs to answer questions about Copilot adoption and acceptance rates across an org or enterprise, and it fits anyone who needs history beyond the API's rolling 28-day window, since the PostgreSQL mode stores per-user daily records and derives team metrics from them. It does not fit someone who expects a read-only dashboard for a single team, because the Direct API mode has no team metrics at all and the team views require the database, and it does not fit an enterprise that has not enabled premium-request billing and expects credit columns, since the AI Credits column shows a dash when GitHub has not reported credits. Before you deploy it, read DEPLOYMENT.md and pick a mode deliberately, check that your GitHub App carries the Organization Copilot metrics: Read permission, and remember that the legacy Copilot Metrics API was shut down on April 2, 2026, so any deployment guide predating v3.0 is describing an API that no longer exists.

Frequently asked questions

Official sources

1. github-copilot-resources/copilot-metrics-viewer on GitHub
2. License: MIT
3. Project website
4. README
5. Releases