GitHub Restricted Stargazer Data. Here's What Broke (and What Didn't)

On June 30, 2026, GitHub published a changelog that most people skimmed past until their Star History chart went blank.

If your README chart is already blank and you just want the fix for a repo you admin, jump to Blank Star History Chart? Fix Your Repo. This article stays on what GitHub changed and how we drew the product boundary.

The short version: the public list of who starred a repository (and when) is no longer public. Only admins and collaborators of that repository can read it.

That one change quietly broke a lot of README embeds, growth charts, and "compare these two repos" demos. It also forced us to rethink how GitHubCard handles Star History.

What GitHub changed

These REST endpoints are now limited to repository admins and collaborators:

GET /repos/{owner}/{repo}/stargazers
GET /repos/{owner}/{repo}/subscribers

GitHub is also deprecating GET /users/{username}/subscriptions (repos a user watches). During the deprecation window it may return empty data; later it goes away.

The website views moved the same way:

/stargazers
/stargazers/you_know
/watchers

If you call those APIs without the right access, you may get 403, 404/Not Found, or an empty list. The exact shape depends on the token and how far the rollout has gone for that repo.

GitHub's stated reason is spam. Public stargazer lists were being scraped to build contact lists. Fair enough. The tradeoff is that growth curves built from "who starred when" are no longer a free public dataset.

Why Star History charts died overnight

Tools like star-history.com (and anything similar) rebuild a cumulative curve from stargazer timestamps. Their servers are not collaborators on your repo. After the restriction, a service token cannot fetch another project's star timeline the way it used to.

So these common cases break:

Live Star History SVGs in READMEs for repos the service does not administer
Public pages that chart any repo you paste into a URL
Side-by-side comparisons of popular projects you do not own

What still works, if you bring a token that can actually read that repo:

Charting a repository you admin or collaborate on
Embedding a chart for your own repo when the backend uses your authorized access (or a token you intentionally provide)

GitHub docs now call this out on the starring REST API page as well.

What this means for GitHubCard

We never promised "Star History for every public repo on the internet." Our product is built around cards for profiles and repositories you actually work on.

After GitHub's change, we made that boundary explicit:

Your repos still get accurate Star History. Sign in with GitHub. If the token lacks enough repository access, we ask you to authorize the extra public_repo scope. That scope is broader than sign-in (GitHub shows it as read and write for public repos). We use it to read star timelines.
Other people's repos do not get a fake curve. If you are not an admin or collaborator, we tell you Star History is unavailable instead of inventing a chart from partial data.
Published cards keep a snapshot. Once you load Star History for a repo you control, we store an aggregate series (dates and totals, not individual stargazer identities) on the widget. Public render paths use that snapshot. They do not re-hit GitHub with a service token on every view.

Everything else on a repo card (title, metrics, languages, commits, contributors, and so on) still works for public repositories the way it did before.

Practical advice if you maintain a repo

Prefer cards for repositories you own or can manage. That matches both GitHub's new rule and how most people use GitHubCard.
If Star History asks for repository authorization after you are already signed in, that is expected. Login scopes (read:user, email, org membership) are not enough for the stargazer timeline anymore.
Do not paste a high-privilege token into a public README unless you understand the blast radius. Prefer the narrowest token you can, or let GitHubCard capture a snapshot while you are signed in and then publish the card.
If an old embed shows an empty chart, open the repo in the repo card editor, add or refresh Star History while authorized, then republish.

What we are not doing

We are not scraping GH Archive or third-party mirrors to reconstruct other people's star timelines. That would paper over GitHub's restriction with weaker data and a messier privacy story.

We are also not pretending a server GITHUB_TOKEN can stand in for "you administer this repo." It cannot.

Bottom line

GitHub closed a spam vector and took public star timelines with it. Annoying if you liked comparing random popular repos. Reasonable if you have ever been spam-harvested from a stargazer list.

For GitHubCard, the path forward is boring and honest: accurate Star History for repositories you control, clear refusal for the rest, and published cards that keep the snapshot you authorized.

Need the repair steps only? Blank Star History Chart? Fix Your Repo.

If you want to try it on one of your own projects, start with the GitHub repo card generator.

GitHubCard Team