GitHub's traffic API forgets in 14 days, and the only key to it says 'administer my repositories'

The permission cannot be engineered away, and the author of a dev.to writeup on building a traffic archiver says the search for a way around it came up empty. A GitHub App that reads `GET /repos/{owner}/{repo}/traffic/views` needs Administration: read, and that is the only scope GitHub publishes for traffic data ^[3]. What is left to a developer is subtraction: request no Contents, no Issues, no Actions, no Secrets, and then write a page explaining why the remaining scope looks the way it does ^{[4] [5]}. The author expected that install screen to be the single biggest reason a prospective user backs out ^[5]. Anyone shipping in this space inherits the same problem, and it is answered with copy rather than code.

Retention of 14 days is also an availability requirement, which is the part that gets discovered late. Polling every six hours means four passes a day across four endpoints, so 16 requests per repository per day and 5,840 in a year ^{[6] [1] [3]}. The figure that matters is on the other side of the ledger: 14 days of window against a six-hour cadence buys 56 consecutive missed cycles before a date leaves GitHub for good ^[2]. An outage inside that budget is recoverable. One past it leaves a hole in the series that no support ticket repairs ^[2].

Each endpoint then bends the storage layer in a different direction. Today's row keeps growing while you watch it, so writes are upserts keyed on (repository_id, metric_date), and both scheduler and store have to speak UTC, because GitHub's day boundaries do ^{[9] [10]}. Referrers arrive as a top-10 snapshot of a rolling 14-day window with no dates attached, so yesterday's entries have to be deleted rather than merged, in one transaction, or a fallen referrer sits in today's snapshot carrying last night's count ^{[11] [12]}. Release download counts only ever climb, so per-release velocity is a diff of consecutive daily readings you took yourself ^[13].

The uniques trap has no engineering answer at all. Uniques are deduplicated within a day, and GitHub never hands over the identity that would let you deduplicate across days, so there is no correct monthly figure, only a sum of daily numbers that counts returning visitors more than once ^[7]. The author shipped that error and had to fix it in five places ^[14]. The column now reads "Daily uniques, 30-day sum", and every export carries a limitations field, on the reasoning that a CSV opened next year has no tooltip to hover over ^[8]. That 30-day label is itself a tell: 16 of those days exist only because someone was writing them down, since GitHub keeps 14 ^{[2] [4]}.

Which makes the archive the asset, and it starts accruing on the day the poller is switched on. A team that decides in March it wants a year of repo reach cannot buy it, request it, or reconstruct it ^[2].