GitHub Locked Down Public Stargazer Lists. Here's What Actually Broke

A repository’s star count is still public. Who starred it, and when, is not anymore. GitHub restricted its stargazers and watchers listing endpoints to admins and collaborators only in July 2026, and the tools built on the old assumption, that this data was as public as the count itself, found out the hard way.

What the endpoint used to do

/repos/{owner}/{repo}/stargazers returned the list of accounts that starred a repository, in order, with timestamps if you asked for them. /repos/{owner}/{repo}/subscribers did the same for watchers. Neither required authentication for a public repository. Anyone, a script, a browser, a bot with no GitHub account interaction beyond an anonymous request, could pull the full list.

That openness is what made a whole category of tooling possible. Star History plots a repository’s star count over time by reconstructing it from exactly this data. OSS Insight built dashboards on top of it. Discovery tools that answered “who’s actually using this library” by looking at notable accounts in the stargazer list depended on it being queryable for repos they had no other relationship to.

Why GitHub says it changed

GitHub’s changelog frames the restriction as an anti-abuse measure. Public stargazer lists had become a target for bots scraping usernames and profile metadata at scale, harvesting exactly the kind of data spam operations want: real, active accounts with an established interest in a specific technical niche. Restricting the listing endpoints to admins and collaborators removes the unauthenticated path those bots were using; a bot with no relationship to a repository can no longer enumerate everyone who starred it.

That’s a legitimate abuse vector to close. The tradeoff GitHub made is closing it by restricting the data entirely, rather than adding rate limiting, CAPTCHA-style friction, or an opt-out for repository owners who wanted their stargazer list to stay public. The community discussion thread on the change makes the case that this took out a legitimate discovery layer along with the abuse path, and GitHub’s response so far hasn’t offered a middle option.

What actually stopped working

Anything relying on /stargazers or /subscribers for a repository the calling tool doesn’t have collaborator access to now gets a 403 or an empty result instead of data. In practice that means:

• Star-growth-over-time charts for any repo the tool doesn’t maintain. Star History and similar tools can no longer reconstruct historical star timelines for third-party projects.
• “Notable users” discovery features that scanned stargazer lists for recognizable accounts to answer “who’s actually adopting this.”
• Any internal dashboard or script a team built against the public endpoint to track competitor or ecosystem repos, not just their own.

What still works: the star count on a repo’s own page, and full stargazer/watcher access for repos where you’re an admin or collaborator. If you maintain a project, you haven’t lost anything, you can still pull your own repository’s full history. The loss is specifically in observing repos you don’t control.

What to do if you relied on this

If you maintain a popular open-source repository and care about historical star data staying available, the practical move is to start exporting it yourself now, while you still have collaborator access, rather than waiting on GitHub to add a public opt-in. A scheduled job hitting the endpoint with your own token and writing the result to a file in the repo, or a separate data store, costs little and preserves the history going forward even if the public endpoint never reopens.

If you’re building on top of someone else’s stargazer data, the honest options are narrower: ask the repository owner to export and publish it themselves, or accept that third-party star-growth tracking for repos you don’t maintain is no longer something the API supports. There isn’t a documented workaround that restores the old behavior, and treating this as a temporary inconvenience rather than a permanent API change is likely to leave a tool broken longer than necessary.

This is also a reminder worth generalizing past GitHub specifically: any product feature or internal tool built on a platform’s implicit openness, an endpoint that happens to be unauthenticated today, is one abuse incident away from a restriction with no announced timeline. If a piece of your stack depends on data a third party controls and doesn’t formally guarantee stays public, an export job you run yourself is cheaper than the rebuild you’ll be doing the day access changes. If your team is auditing dependencies like this across a product, our engineering team has done exactly this kind of platform-risk review for clients building on top of third-party APIs, and it’s a good exercise to run before the next changelog post catches you by surprise, not after.