How to tell if GitHub stars are real

September 18, 2026 · 11 min read

GitHub has spent years turning stars into the platform's universal quality signal. Developers use them to pick dependencies, investors use them to filter companies, and search algorithms use them to order results. Which is exactly why an industry grew up around manufacturing them.

The most detailed study of that industry, published at ICSE 2026 by researchers at Carnegie Mellon, North Carolina State and Socket, identified six million suspected fake stars across 18,617 repositories. By July 2024, one in six repositories with more than 50 stars had been part of a fake-star campaign. The stars you are looking at are more likely to be manufactured than they were five years ago, and the tools designed to check them are mostly out of date.

This guide covers what changed in 2026, which signals are still public, and how to read them. It applies whether you are vetting a dependency, comparing a competitor, or auditing your own repository.

Check 1: The fork-to-star ratio

This is the strongest public signal in the research, and it takes ten seconds. Stars cost one click; forks cost actual effort, because a developer has to decide your code is worth copying into their own account. Accounts created to deliver stars are not forking anything.

The study's benchmarks are specific: a long-lived comparison project runs at 0.235 forks per star, while a manipulated repository flagged in the campaigns sat at 0.017 - roughly one fork for every fifty-eight stars. Independent write-ups converge on the same rule of thumb: healthy tools and libraries usually run between 0.1 and 0.3, and anything below 0.05 with a substantial star count deserves scrutiny.

# fork ratio in one command (gh CLI)
gh api repos/OWNER/REPO --jq \
  '"\(.stargazers_count) stars, \(.forks_count) forks, ratio \(.forks_count / .stargazers_count | . * 100 | round / 100)"'

A high ratio proves engagement, not quality. A near-zero ratio proves that engagement never happened - whatever the star count says.

Check 2: Watchers, not stars

Watching is opt-in and deliberate: a watcher asked to receive notifications about every future release, issue and discussion. It is a much stronger statement of intent than a star, and it is the second thing bought stars fail to replicate. Fake accounts star; they do not subscribe to updates.

There is no universal number to compare against, because watcher counts scale with repository age and activity. What matters is the relationship between stars and watchers. Real audiences leave a trail of watches; a repository with five figures of stars and double-digit watchers is telling you the stars arrived without the audience. Compare against two or three healthy repositories in the same ecosystem at similar age - the gap is usually obvious.

Check 3: The shape of the curve

Fake stars come in two shapes, and the study named them: the low activity signature (empty accounts starring in a burst) and the lockstep signature (networks of accounts starring repos in coordinated batches). Both leave the same public trace: a vertical line in the history where a gradual slope should be. The data for this is still public through the new endpoint:

curl -s "https://api.github.com/repos/OWNER/REPO/stargazers/history" \
  | python3 -c "import json,sys
data = json.load(sys.stdin)
for week in data[:8]:
    print(week['week'], 'total:', week['total'], 'days:', week['days'])"

The response is a list of weeks, newest first, each with a total and an array of seven daily counts - aggregate numbers, no identities. Reading it is mostly about correlation. A spike on its own proves nothing: a Hacker News front page can add hundreds of stars in a day, and the launch study behind our first-100-stars guide measured an average of 121 stars in the first 24 hours for a successful launch.

The question is whether anything external explains the spike. Did the repository trend? Was there a release, a conference talk, a widely shared post? A step that matches an event is a launch. A step that matches nothing is a delivery - and there is usually a second step when the next order lands.

Check 4: The activity audit

Stars can be bought; a working community cannot. Open the contributors list, the issue tracker and the release history, and look for the things that cost someone time:

• Contributors. A healthy project has multiple contributors with meaningful histories, not one maintainer and forty passers-by. git shortlog -sn on a clone answers this in seconds.
• Issue flow. A repository with thousands of stars and zero open issues is not battle-tested - it is either unused or hiding its feedback. Real projects accumulate bugs faster than they close them.
• Releases and commits. Growth follows shipping. The research on star growth consistently shows engagement accelerating after releases and flattening when projects go quiet.
• Usage evidence. Package downloads on npm and PyPI are harder to fake than stars, and dependent repositories are harder still. If the registry numbers and the star numbers tell different stories, believe the registry.

If the numbers don't add up

For most readers, the practical outcome is a decision: trust the repository, watch it, or walk away. If a dependency's stars look manufactured, treat its adoption as unproven and test it the old way - clone it, run the examples, check the issue tracker, search the package registry. If you are comparing a competitor's repository, remember that manufacture follows order flow: one unexplained step may be a test order, and the second step is the tell.

If it is your own repository, you have privileges the public does not: admins and collaborators still get full stargazer access, so you can audit your own list, watch removal patterns, and export the accounts behind a spike. If you have bought growth, compare the curve against the delivery window - paced orders look like a slope, single-burst orders look like a step, and the difference is the entire argument for pacing. We wrote the pricing breakdown for that side of the question.

FAQ

How can I tell if GitHub stars are fake?

Check three public signals: the fork-to-star ratio, the watcher count relative to stars, and the shape of the growth curve. The ICSE 2026 fake-star study cites an organic comparison project at 0.235 forks per star and a manipulated repository at 0.017 - one fork for every fifty-eight stars. Spikes look bought; slopes look real.

Did GitHub remove the stargazers list?

For everyone except repository admins and collaborators, yes. On June 30, 2026 GitHub restricted the stargazers and watchers endpoints and views to protect user privacy. On September 4, 2026 it released a privacy-safe replacement: a public star history endpoint that returns weekly and daily star counts without exposing who starred. Most fake-star guides still describe the old method, which now returns 404.

Is a sudden star spike always fake?

No. A launch on Hacker News can add hundreds of stars in a day, and the 2025 launch study measured an average of 121 stars in the first 24 hours. The question is whether anything external explains the spike. The fake-star research found that even purchased spikes only help for under two months, after which they become a liability.

Can a repository get removed for fake stars?

The study suggests it happens often: 90.42% of the repositories StarScout flagged were eventually deleted by GitHub, while only 57% of the accounts behind them were cleaned up. GitHub's terms prohibit fake stars, and enforcement follows the freshest signature - new accounts starring in synchronized bursts.

What fork-to-star ratio is normal?

For tools and libraries, a common healthy range is roughly 0.1 to 0.3 forks per star. The ICSE study cites a long-lived organic project at 0.235 and a manipulated repository at 0.017. Ratios below 0.05 with a high star count are the strongest public red flag.

How do I audit stars on a repository I own?

Admins and collaborators still get full stargazer access through the GitHub UI and API, so you can review accounts, watch removal patterns, and export the list. Compare your curve against the delivery window: paced orders look like a slope, single-burst orders look like a step.

Sources

• He, Yang, Burckhardt, Kapravelos, Vasilescu, Kästner. Six Million (Suspected) Fake Stars on GitHub. ICSE 2026. DOI 10.1145/3744916.3764531.
• GitHub Changelog. Upcoming access restrictions to public API endpoints and UI views. June 30, 2026.
• GitHub Changelog. New API endpoint provides privacy-safe star history data. September 4, 2026.
• Carnegie Mellon University, School of Computer Science. Fraudsters Use Fake Stars To Game GitHub. September 2025.
• Dagster. Detecting Fake GitHub Stars with Dagster. March 2023.
• Borges, Hora, Valente. Characterizing the Usage of GitHub Stars. 2018.