GitHub Restricted the Stargazers API. Here's What Breaks If You've Been Using Star Counts as Social Proof
If you've got a star-history chart embedded in a README for a repo you don't personally maintain, it stopped updating on June 30. Not because the chart broke. Because GitHub cut off the data feed it depends on. Every non-collaborator request to the stargazers endpoint now comes back 404, and there's no workaround short of getting added to the repo.
I noticed this the way most people did: a chart on a landing page I'd been pointing to as evidence of traction just stopped moving. Went to check the API directly and got "Not Found" on a public repo that very much has stars. That's when I went and read the actual changelog entry instead of guessing.
What GitHub actually changed
The changelog post, dated June 30, 2026, restricts two REST endpoints to a repo's own admins and collaborators: the List stargazers endpoint (/repos/{owner}/{repo}/stargazers) and the List watchers endpoint (/repos/{owner}/{repo}/subscribers). A third endpoint, List repositories watched by a user (/users/{username}/subscriptions), is being deprecated on a slower timeline: it currently returns empty responses, with full removal to follow.
Three UI views went dark along with the API: the repository stargazers page, the "You Know" stargazers tab, and the watchers page. GitHub's own copy says affected requests "may begin receiving empty responses or a 403 Forbidden status." In practice, that's not what people are seeing. A GitHub community discussion opened the following week by developer davidmezzetti states it plainly: as of June 30, all repositories return a 404 for /stargazers. Star-history.com's own postmortem confirms the same thing: an authenticated request for a repo you don't own now comes back "Not Found," full stop.
Here's the part that matters for anyone leaning on stars as a metric: the total star count is untouched. That number still renders on the repo page and still comes back from the standard repository API call as stargazers_count. What's gone is everything downstream of the raw number: who starred, when, and the timeline you'd need to plot growth over time.
Why GitHub says it did this
The stated reason, straight from the changelog: these endpoints "expose public lists of stargazers and watchers, and this information has increasingly been misused to collect user data for spam activities." GitHub frames it as reducing data misuse and strengthening platform trust, not as a move targeted at growth dashboards or marketing tooling.
I believe that's the actual motivation, not a cover story. A public list of usernames tied to a specific interest signal (this person likes this kind of project) is exactly the shape of data spam operations want, and scraping every popular repo's stargazer list at scale is a real, well-documented pattern. The community discussion thread has replies from both sides: one commenter calls it a proportionate response to bot rings scraping user lists, another argues GitHub could've solved this with rate limits and abuse detection instead of pulling the endpoint entirely for everyone. Both are reasonable positions. GitHub picked the blunter one.
What actually breaks for solo operators
If you've been doing indie marketing on GitHub, you're probably touching at least one of these.
Star-history embeds in READMEs and landing pages are the most visible casualty, and it's the one I ran into first: the landing page chart from the intro is exactly this failure mode. Star-history.com's blog confirms live charts for repos you don't own or collaborate on can no longer render, because their servers hit the same restricted endpoint your browser would. That "star growth chart" screenshot you've been using in a pitch deck is now a static image of a moment that already passed.
Growth dashboards tracking a competitor's or an ecosystem's star velocity are next. If you've built anything that watches star counts across a category to spot which tools are gaining traction, that data source is gone for every repo outside your own org.
The quieter loss is fraud detection. A commenter on the GitHub thread, developer Yiling-J, described using the stargazers list specifically to spot fake-star campaigns: if a cluster of accounts had all starred the same suspicious set of repos, that overlap was a real signal something was gamed. That check doesn't work anymore either, for anyone but the repo owner. Which is a strange side effect, since the same restriction that stops spammers from harvesting stargazer emails also stops the rest of us from catching repos that bought their stars in the first place.
What still works
If you're a collaborator or admin on the repo, nothing changes for you: the endpoints still return full data with an authenticated token. Star-history.com's guidance for this case is specific and worth knowing if you maintain your own project's chart: you now need a token with actual read scope. Tokens created with no scopes at all stopped working too, even for your own repositories, so if your embed suddenly broke and you do own the repo, check your token before you assume the feature died.
And again, the raw count survives everywhere. Repo page, API response, badge services that only ever pulled the aggregate number. If your "12,000 stars" badge was hitting the count endpoint and not the stargazers list, it's fine.
The honest take
Stars were never a great proof point, and this change is a decent excuse to stop treating them like one. A star costs a user one click, it's not tied to actual usage, and the fake-star economy around it is well established enough that sophisticated buyers have started discounting star counts on sight. I've watched this happen in real conversations: someone pitches "10K stars" and the person across the table asks how many of those converted to actual users, and there's usually an awkward pause.
What I'd actually do here: replace the star chart with something GitHub can't 404. Usage telemetry from your own product, opt-in and aggregated, is yours to keep showing regardless of what any platform does, and testimonials with real names attached carry more weight than an anonymous list of usernames ever did anyway. If you're comfortable sharing revenue or MRR, that beats both, since nothing signals real adoption like people paying for the thing, though I get why most operators keep that number private. None of this requires a third-party API that can change its access rules on a Tuesday and take your social proof down with it. Stars can stay on the README as a nice-to-have. Just stop building your pitch around a number a platform you don't control decided, correctly or not, to lock down.
Author
Lukas
@lukcombinator