Primary source: https://github.blog/changelog/2026-07-17-github-copilot-app-now-available-in-the-usage-metrics-api/.
GitHub added Copilot app activity to the usage metrics API on July 17. When a source or product surface enters a metric, historical totals may arrive late or change meaning. A dashboard that overwrites rows cannot explain yesterday's number.
metric key = repository + day + surface + definition_version
observation = value + fetched_at + source_revision
Store append-only observations, then materialize the latest accepted revision. Test these sequences:
| Sequence | Invariant |
|---|---|
| same page fetched twice | no duplicate logical row |
| late app data arrives | revision increases |
| repository renamed | stable ID preserves series |
| definition changes | old and new versions not merged |
| backfill races daily job | deterministic winner |
A small simulator should permute ingestion order and assert that the materialized view converges for the same observation set. Keep provenance so reports can be reproduced as-of a prior timestamp.
This pattern does not claim GitHub will revise historical data; it prepares for late, duplicated, or definition-changing telemetry common to usage systems. Does your metrics store preserve what the dashboard knew yesterday?
