Why GitHub Only Gives You 14 Days - and How Gitlytics Fixes It

The 14-day wall

Open any repository's Insights → Traffic tab on GitHub and you'll see a clean little graph of views and clones. Scroll back far enough and the data just stops. Not archived, not paginated - gone. GitHub's Traffic API and the corresponding UI only retain 14 days of views, clones, referrers, and popular-path data. There's no export button, no API parameter to request more, and no official way to back it up before it disappears.

For a repo that ships slowly, 14 days can vanish before you even notice a spike happened. A blog post goes semi-viral, gets you on Hacker News' front page, drives a wave of traffic - and two weeks later the only proof it happened is your own memory.

Why does GitHub do this?

GitHub has never published a detailed rationale, but a few likely reasons line up with how the platform is built:

• Scale. GitHub hosts hundreds of millions of repositories. Storing unlimited daily traffic granularity for every one of them indefinitely is a meaningfully different storage problem than a rolling 14-day window.


• Privacy posture. Traffic data includes referrer URLs and visitor counts. A short retention window limits how much behavioral history accumulates per repo, which simplifies GitHub's own privacy and data-retention obligations.


• It was never meant to be an analytics platform. The Traffic tab reads like a debugging convenience - "did anyone see this" - not a growth-analytics product. GitHub has consistently left deeper analytics to third parties rather than building it out itself.

Whatever the reasoning, the practical result is the same: if you care about long-term trends - growth after a launch, the effect of a README rewrite, which referrer sources compound over months - GitHub's own UI cannot answer that question for you.

What actually gets lost

Every day past the 14-day window, GitHub silently drops:

• Daily views and unique visitors


• Daily clones and unique cloners


• Referrer sources (where traffic came from) and their per-referrer counts


• Popular content paths and their per-path counts

There's no warning before it happens. There's no way to request a longer window, even temporarily. And because the API mirrors the UI's retention exactly, writing your own script to hit the endpoint doesn't help unless you're already running it before the window closes.

The three ways to actually solve this

Gitlytics was built specifically around this gap, and it gives you three ways to solve it depending on how much infrastructure you want to run:

1. CLI + Python library - you own the data

pip install gitlytics
gitlytics sync --data-dir ./data

gitlytics sync fetches your current 14-day traffic window and appends it to local CSV files (traffic_YYYY-MM.csv), deduplicating by repository and date so you can run it as often as you like without creating duplicate rows. Point a cron job or --schedule-cron at it and you have a permanent, append-only traffic history sitting in files you control - no servers, no third-party storage.

2. GitHub Action - zero infrastructure, data lives in your repo

Add gitlytics-action to a workflow and it runs on a schedule (every 13 days, one day inside GitHub's 14-day window as a safety buffer), fetches traffic, and commits the CSV straight back into your repository:

- uses: ameyachopade/gitlytics-action@v1
  with:
    traffic_token: ${{ secrets.TRAFFIC_TOKEN }}

Your traffic history becomes part of your repo's own commit log - versioned, diffable, and backed up wherever your repo is backed up. No dashboard, no database, nothing to maintain.

3. Cloud dashboard - nightly sync, zero maintenance

For repos you don't want to babysit, [dashboard.gitlytics.dev](https://dashboard.gitlytics.dev) connects via GitHub OAuth, pins up to 3 repositories per workspace, and refreshes traffic automatically every night. History is stored server-side and stays available indefinitely - free, with no CLI or Action setup required.

Which one should you use?

| If you want... | Use |
|---|---|
| Full control, data in your own files | CLI + Python library |
| Traffic history versioned inside your repo, zero external services | GitHub Action |
| A dashboard with charts and zero maintenance | Cloud dashboard |
| All of the above at once | Combine them - the CLI/Action write CSVs, the dashboard can import CSV data directly |

The takeaway

GitHub's 14-day limit isn't a bug you can work around by asking nicely - it's a hard platform constraint. The only real fix is capturing the data before the window closes and storing it somewhere that isn't subject to GitHub's retention policy. That's the entire premise Gitlytics is built on: three lightweight ways to make sure the traffic your repo generates today is still there a year from now.