Traffic statistics for my public repositories appear to have stopped updating after **2026-09-23**.

[topquark22]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

API

Body

Public repository traffic statistics frozen since Sept 23; private repository traffic windows still advance

Traffic statistics for my public repositories appear to have stopped updating after 2026-09-23.

The problem is visible both in the GitHub Insights → Traffic web interface and through the REST traffic API.

For example, for the public repository topquark22/GHTraffic, on September 26 I queried:

GET /repos/topquark22/GHTraffic/traffic/views?per=day
GET /repos/topquark22/GHTraffic/traffic/clones?per=day

Both requests succeed normally, but their daily data ends on September 23.

The GitHub Insights → Traffic page for the same repository also ends on September 23.

This does not appear to be zero traffic

The distinction between a missing daily bucket and zero traffic seems important here.

For topquark22/GHTraffic, the views endpoint currently contains explicit zero-valued records such as:

2026-09-21: 0 views
2026-09-22: 0 views
2026-09-23: 0 views

But there are no daily records at all for September 24, 25 or 26.

The clones endpoint similarly stops at September 23.

By comparison, my inactive private repositories are continuing to receive daily buckets through September 26, including explicit records containing:

0 views
0 unique visitors
0 clones
0 unique cloners

So GitHub is continuing to advance the traffic window for private repositories even when there is no traffic, while the traffic window for the affected public repositories stops completely on September 23.

Public/private comparison

I maintain a local historical database of responses from GitHub's traffic API.

Among the repositories represented in that database:

Visibility   Repositories   Repositories with traffic buckets after Sep 23

public       17             0
private      22             14

All 17 public repositories represented in the database have exactly the same latest traffic date:

2026-09-23

None has even a zero-valued daily bucket after that date.

Fourteen of the 22 private repositories have daily buckets after September 23, through September 26. I inspected these records and confirmed that inactive private repositories have zero-valued daily buckets, as expected.

I have more public repositories than the 17 represented in this local traffic dataset, so this is not intended as an exhaustive test of every public repository on my account. However, the 17 for which I have historical traffic data all show the same cutoff.

Example REST response

For topquark22/GHTraffic, the views API currently returns a 14-day sequence beginning September 10 and ending September 23:

2026-09-20: 36 views
2026-09-21:  0 views
2026-09-22:  0 views
2026-09-23:  0 views

There are no entries for September 24–26.

The clones endpoint likewise ends on September 23.

This repository has had development activity since September 23, including commits and release activity, so the absence of subsequent clone statistics is also unexpected.

Authentication appears normal

The API requests complete successfully; there are no authentication or permissions errors.

The same collector, credentials and database continue to receive current traffic buckets for private repositories. Collection timestamps confirm that the public-repository endpoints are still being queried successfully on September 26; they are simply returning a daily series that ends on September 23.

This therefore appears to be an issue with GitHub's traffic-statistics aggregation for public repositories rather than an API client, authentication or permissions problem.

Is anyone else seeing public repository traffic statistics frozen at September 23?

If this is a GitHub-side processing issue, will the missing September 24 onward statistics be backfilled once traffic processing resumes?

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[TeWei02]

The public/private split is the tell here: private repos keep advancing zero-valued buckets while the affected public repos stop dead at Sep 23. That rules out "no traffic" and points at the public aggregation job, since an inactive public repo still receives empty daily buckets once the aggregator has caught up.

Two quick checks before filing anything:

1. Request the same window with a weekly bucket. Daily and weekly aggregation for public repos are computed separately and do not always lag in lockstep:

gh api "repos/topquark22/GHTraffic/traffic/views?per=week" --jq '.views[-3:]'
gh api "repos/topquark22/GHTraffic/traffic/clones?per=week" --jq '.clones[-3:]'

If the weekly buckets reach Sep 24-26 while daily stops at Sep 23, that confirms missing daily buckets rather than a counter reset.

2. Hit the other traffic endpoints, which are fed by a different job:

gh api repos/topquark22/GHTraffic/traffic/popular/referrers --jq '.[0:3]'
gh api repos/topquark22/GHTraffic/traffic/popular/paths --jq '.[0:3]'

popular/* advancing normally while views and clones are frozen isolates it to the aggregation step.

Traffic data is documented as delayed and it does get backfilled, in order, so do not treat Sep 24-26 as lost yet. Re-query the same range in 48 hours. If the buckets appear, that was normal lag and there is nothing to report. If the gap stays empty while your private repos keep advancing, file it with the repo name, the commands above, and your local DB summary -- 17 public repos with nothing after Sep 23 versus 14 of 22 private ones still receiving buckets is the kind of evidence that can be routed to the right team.

Two things worth ruling out. If any of those 17 are forks, their traffic is not collected at all -- fork traffic belongs to the parent network, and it shows up as a permanently empty window rather than a lag. And repos created inside the window will not have buckets before their creation date, which can look like the same thing.

One caution about your local DB: the window only reaches back 14 days for per=day, and backfilled buckets replace the range rather than appending to it. Plan a full re-fetch of the gap once it fills instead of an append, otherwise you will duplicate rows for Sep 21-23.

If the public/private split matches what you are seeing across the rest of your repos, marking this as the answer will help others with the same frozen window find the cause faster.

[topquark22]

I ran both suggested checks.

per=week does not appear to be ahead of per=day. The current Sep 21 weekly clone bucket is 8 clones / 8 uniques, which exactly equals the available daily data:

• Sep 21: 5 clones
• Sep 22: 1 clone
• Sep 23: 2 clones
• Total: 8

There is still no evidence of Sep 24–26 being incorporated into the weekly bucket.

popular/referrers and popular/paths return successfully, but those responses contain no timestamps, so I can't determine whether their data has advanced past Sep 23.

This also rules out the fork explanation for my sample: my collector excludes forks during repositorydiscovery.

My collector already performs an upsert keyed by (repository_id, traffic_date), so if GitHub backfills the missing dates, subsequent collections will insert the missing buckets and update overlapping ones without duplication.

[dnaspider]

Same. Frozen @ 9/23. Not the first time... Happens ever so often. Will be there probably tomorrow or so.

[yluo1]

Ditto. Two public repos of mine are also frozen since 9/23.

[hupe13]

Same. Both Insights -> Traffic and if I query the statistics via API. This applies to all my repositories.

[hrodrig]

Same here for all public repos under @hrodrig (e.g. hrodrig/groot, hrodrig/pgwd, hrodrig/kzero, hrodrig/gghstats).

Facts

• Insights → Traffic UI and REST GET /repos/{owner}/{repo}/traffic/views + /traffic/clones: last daily point 2026-09-23
• Checked 2026-09-28 (UTC) — ~5 days with no new daily buckets (not explicit zeros after the 23rd)
• API returns 200 with a stale 14-day series (not 403) — auth/permissions look fine
• Local collector (gghstats) hourly sync: repos=27 failed=0 — it is reading GitHub successfully; GitHub just stops at 2026-09-23

Support

Also tracking via GitHub Support ticket #4801605 (reopened after an initial self-service close).

If this is a public-repo aggregation stall: will 2026-09-24+ be backfilled once processing resumes?

[kurupdevs]

Your read is right: missing buckets versus explicit zeros means the traffic pipeline stalled, not that you got zero traffic. Traffic stats are best-effort and computed by a batch pipeline that can lag by days, and public-repo traffic has had multi-day stalls before. Nothing to fix on your end — the API returning 200 with data ending Sept 23 plus Insights agreeing means it's a GitHub-side delay. It usually backfills when the pipeline catches up. Worth keeping an eye on githubstatus.com, and if it's still frozen after about a week, open a support ticket since you have concrete API evidence.

[jpezzulli]

My public repository, jpezzulli/sglang-rtxpro6000, has traffic statistics frozen through September 23, 2026. As of September 28, both Insights → Traffic and successful REST views/clones requests with per=day still return September 10–23. Referrer and popular-path responses are also unchanged. This matches discussion #208852.
Please confirm whether this repository is affected by a known incident. Thanks.

[deepjyoti-dev]

Adding another confirmation here—all of my public repos are also frozen dead on Sept 23, while private ones are tracking fine. Definitely looks like another batch processing stall on GitHub's end. Hopefully, it clears and backfills soon like it usually does.

[yabwon]

I have exactly the same issue. No data after Sept. 23rd

[yabwon]

Looks like reporting on my 15 repos got back to normal... Flingers crossed it stays this way! 🤞

[paupawsan]

Same here. No data after Sept. 23rd

[tabith-llc]

Same here, no data after September 23.

[kurupdevs]

Your diagnosis is spot-on, and the zero-vs-missing distinction you drew is the key detail: explicit 0 rows mean the aggregation pipeline ran that day, while missing days mean it never wrote the bucket at all. Combined with your private repos still advancing through Sept 26, this is clearly GitHub-side — nothing wrong with your collector, token, or auth.

The timing gives away the cause. GitHub's status timeline shows an incident starting 6:11 AM ET on Sept 23 — "Database replicas have detached," with degraded API requests and Projects — marked resolved early on Sept 24. Your freeze starting on Sept 23 lines up with that incident exactly.

That incident's symptoms were all background-processing delays (stale search indexes, issue label updates lagging by hours). Traffic aggregation is the same class of background job, so a stall in daily bucket writes fits the pattern. The fact that all 17 of your public repos froze on the same date while private repos kept getting fresh buckets rules out anything account- or client-side — it points at the public-repo aggregation path specifically.

On your questions:

1. Backfill: when aggregation resumes after an incident like this, GitHub usually replays the raw request logs and the missing days show up late — but that's not guaranteed. Note the traffic API only returns the last 14 days, so every day the freeze persists pushes the oldest frozen day out of the window. Your local database snapshots are the safety net here, so keep collecting daily.
2. What to do now: nothing to fix on your side. Watch one quiet public repo — when new buckets (including explicit zeros) start appearing again, the pipeline is healthy. If the missing Sept 24–26 days still haven't appeared a few days after the incident was resolved, open a GitHub Support ticket referencing the Sept 23 replica-detach incident and ask whether a backfill of traffic aggregation is planned.

[ajax80]

Same freeze at 2026-09-23, but on my account it's not public-only: private repo ajax80/AirZDownRepo also stops at 09-23 (zero-valued buckets through 09-23, none after). Weekly buckets for public ajax80/schema-init exactly equal the daily sum through 09-23, so no post-09-23 data is aggregated anywhere.

[zmcddn]

Same here for all my public repos, all traffic data cut off at 2026-09-23

[AhmedYehia-M23]

Same here — public repo traffic has been frozen since Sep 23 in both Insights and the API. I also reported it in #208932.

[AndyCappDev]

Same here. No data after Sept. 23rd

[imshaikot]

Same here, no traffic data since 23rd Sept

[tuoping]

Same here, no traffic data since 23th Sept.

[facebey]

Me pasa exactamente lo mismo repositorio publico congelado el 23 de septiembre.

[igurss]

Same situation, no data after Sept 23.

[9pings]

Same for all my repos

[andrewkushnerov]

Same issue here, confirming. Traffic (views and clones) in 2 public repos stopped at Sept 23

[GitOwl58]

Same here, confirming.

[KikeVen]

Same here, no traffic data since 23rd Sept.

[saadbhattii]

Same situation, no data after Sept 23.

[AVPscan]

Same situation, no data after Sept 23.

[AVPscan]

Everything is working now — thanks everyone!

[hrodrig]

@topquark22

Update from GitHub Support (2026-09-29)

I opened a Support ticket about this. Their reply (paraphrased):

• They are receiving reports from multiple customers
• They have engaged the traffic repository engineers
• They will update when they have a response

Still no public status-page / incident note that I can see — but at least engineering is looped in via Support.

Open questions still matter for collectors:

1. Will 2026-09-24+ be backfilled once fixed?
2. Until then, treat HTTP 200 + frozen window as stale upstream (do not write duplicate fake days).

Tracking detection/write-guard here: gghstats#80.

[AVPscan]

My public repo AVPscan/Math had 998 clones (cumulative, 14-day window) as of 2026-09-23. After that date — no new data points in both Insights UI and API. Not zeros — the series just stops on 09-23. All my other public repos show the same pattern.

This is not a quiet repo. 998 clones in 14 days is steady traffic, then a hard stop on the same date as everyone else in this thread.

Can GitHub confirm:

Is traffic still being collected (just not displayed)?

Is there an ETA for the fix?

Thanks.

[dmitry-bublikov]

I can confirm the same issue for another public repository. Insights → Traffic for dmitry-bublikov/NaCl-superstructure-simulator has also stopped updating after September 23. GitHub Support ticket #4806095 redirected me to Community Discussions.

[samus-aran]

Hi everyone. Thank you raising this. As some of yous have already shared from Support tickets our team is actively looking at this. We can share that we are in a process of shipping a fix and that your data should be backfilled. We will update this thread when we have any further updates.

[facebey]

Thanks for the information; we look forward to hearing from you.

[facebey]

Thank you very much; I can see the metrics again now. Regards.

[hrodrig]

Thanks for the update — much appreciated. Glad the team is on it and that a backfill is planned. Looking forward to the follow-up here.

Hermes

[facebey]

It looks like it's already been resolved, my friend.

[tabith-llc]

resolution confirmation

[KikeVen]

I checked this morning and I was able to retrieve my data, I was expecting a spike after the 23rd, but when it went down I was disappointed

[samus-aran]

Hi everyone. The fix has been shipped so you should be able to retrieve your traffic stats. Thanks again everyone for coming to the community (and Support) to inform us.

[topquark22]

It is working now for me. Thank you for your attention.