The GitHub Star Audit Teardown: Deck Claim to Organic Range

This is the audit I run when a dev-tool startup's deck leans on its GitHub star count. One claimed total goes in, and an organic-star range plus a one-word verdict comes out. It is for early-stage investors, platform and talent partners, and angels who need to know how much of that number is real developer interest before it goes to partners or sets the price of a round. It works under the current access rules, where outsiders can no longer list who starred a repository.

What star data can an outsider still see?

An outsider can still see the live total, a daily curve of stars that are still active, and a public event archive that now records under a fifth of star events. Who starred, and exactly when, is visible only to the repository's admins and collaborators, so every account-level fact has to come from the founder.

GitHub restricted the list-stargazers and list-watchers endpoints to admins and collaborators, and the same lockdown covered the GraphQL Repository.stargazers connection. Any method that starts with "pull the stargazer list and inspect the profiles" assumes access an investor no longer has. For outsiders, the replacement is GET /repos/{owner}/{repo}/stargazers/history. It returns stars grouped by calendar week, most recent week first. Each week carries a days array with the number of stars created on each day, starting on Sunday.

Three properties of that endpoint shape everything below:

• Day is the finest unit. You get no hours and no accounts.
• It counts only stars that are still active. GitHub keeps no historical record of unstars, so a star that was created and later removed disappears from the day it was created.
• Boundaries drift. Week and day boundaries are not guaranteed to align with UTC, so a launch near midnight can split across two days.

GH Archive is a public record of GitHub events, and a star shows up in it as a WatchEvent. Its BigQuery copy updates every hour, and 1 TB of processing a month is free. It was the backbone of fake-star research, and it has thinned out badly. Measured against the stargazers API, its capture rate fell from a baseline of roughly 95 to 100% into the 60 to 70% range in June 2025. It then collapsed to 10 to 20% in February 2026 and has stayed there. On a public ClickHouse mirror, archive WatchEvent rows fell from about 2.03 million in March 2026 to about 69,000 in August.

The case this teardown follows

The running case is a seed-stage dev-tool deck whose star slide reads 2,850. The slide has a date, a cumulative chart that only goes up, and a line saying the growth is organic. I carry it through all seven steps, including two places where my first read was wrong.

I set the claim at 2,850 because that is the reported median star count at seed financing in an analysis of 80 developer-tool companies by Jordan Segall, a partner at Redpoint Ventures. The same analysis put the Series A median at 4,980. I have only seen it through secondary reports, not the primary post. Treat it as a rough anchor for what founders think they need to show, not a pass mark.

The case is a composite. Every count in it is either a published figure or arithmetic on one. Where a real audit would produce its own number, I say what to write down instead of making up a value.

The base rate is why the audit is worth half a day. StarScout, a peer-reviewed study that scanned more than 20 TB of GH Archive data, found 18,617 repositories with fake star campaigns. Those campaigns involved 301,000 participating accounts and 3.81 million fake stars. The authors also found that fake stars only give a promotion effect in the short term, under two months. A deck that still leans on a bought spike months later is leaning on a number that only matters on the slide.

The audit procedure, step by step

The audit has seven steps and takes three to five and a half hours of analyst time, spread over about a week of calendar time that is mostly spent waiting on the founder. Each step has a "done" state you can check. The archive step also has an explicit result for when the data is too thin to say anything.

Sources disagree on the order. Practitioner posts lead with the fork-to-star ratio as "the check that takes thirty seconds". StarScout starts from star events. I compute the ratio at step 1 because it costs nothing, but I do not read it until step 5, once I know the category and whether downloads tell a different story. Reading the ratio without that context is the fastest way to accuse an AI dev tool of fraud it did not commit.

# Step 1: pin the claim
Deck figure: ______   Deck date: ______
GET https://api.github.com/repos/OWNER/REPO                      -> stars, forks, subscribers_count
GET https://api.github.com/repos/OWNER/REPO/stargazers/count     -> live total, dated: ______
Gap (deck minus live): ______
Triage ratios (do not read yet): forks / stars = ______   subscribers_count / stars = ______

# Step 2: daily curve
GET https://api.github.com/repos/OWNER/REPO/stargazers/history   -> page until weeks run out (up to 30 weeks per page)
Reverse to oldest-first, unpack days[] from Sunday, write date,stars
Sum of CSV = ______   Live total = ______   Match: yes / no

# Step 4: archive pass, per spike window START to END
archive_n = WatchEvents on OWNER/REPO in window
history_n = history-endpoint stars for the same days
capture rate = archive_n / history_n = ______
Low-activity: actors whose only WatchEvent ever is this repo, plus at most one other event in this repo that day
Lockstep: 50+ actors who together starred 10+ repos, each repo getting 25+ stars from them inside one 30-day interval
Result: flagged share ______  OR  "archive coverage insufficient"

# Step 5: usage
Downloads pulled in chunks of 18 months or less: ______
Dependents: ______

Teardown: what went right and wrong at each step

Two wrong turns came up in the case. A gap between the deck and the live count looked like fraud, and a launch-day spike looked bought. Evidence later in the procedure settled both, which is why no single step is allowed to produce the verdict.

Step 1: the gap I almost called fraud

The live count came in below the slide's 2,850. My first instinct was that a purged campaign explained the gap. That was premature, because a gap between a dated deck and today's count has three explanations:

• Ordinary unstars. People remove stars, and the endpoint keeps no record of them.
• A bought batch that decayed or was removed. In Dagster's purchase test, a cheap vendor's stars were 75% gone after one month. A premium vendor's 100 stars arrived within 48 hours and were all still there a month later.
• A deck figure that was never accurate.

Outsiders cannot tell the first two apart, because no unstar history exists. The arithmetic shows why the gap matters anyway. A cheap 100-star batch shows on today's curve as about 25 stars on the day it was bought, while a deck written the week after the purchase still counts all 100. I wrote down the gap with both dates and carried it to step 6 as a question, not a finding.

Step 2: pulling the curve

A repository needs one request for every 30 weeks it has existed, up to a cap of 100 pages. Daily Stars Explorer, an open-source tool that pages this endpoint, works without a personal access token at roughly 1 to 33 requests per repo, which fits inside the unauthenticated limit of 60 requests an hour. For scale, GitHub's own rebuild cut a roughly 251,000-star repo's full history from about 2,511 requests to about 24.

Reverse the weeks into oldest-first order, unpack each days array starting on Sunday, and sum. The sum should match /stargazers/count, because both count active stars only. If the two do not match, pull again before you analyse anything.

Step 3: two spikes, one explained on paper

No one has published a day-level spike threshold, and StarScout works in monthly windows. My working rule is to mark any day that stands well clear of its trailing weeks, then look at the 30 days around it, because that is the interval StarScout's lockstep rule uses. Match each spike to a public event such as a release tag, a launch post or a talk, with one day of tolerance for boundary drift.

The case had two spikes. Spike A fell on the day of the launch post, so I labelled it explained on paper. Spike B had no release, post or talk within a day either side, so I labelled it unexplained.

This was the second wrong turn. Before I checked the dates, I had spike A marked as suspect. A single-day burst is exactly what a purchase looks like. Launch traffic also produces exactly the accounts that fit the low-activity signature: someone arrives from the post, stars once, and never acts on GitHub again. Check the date against the launch post before you look at anything else.

Step 4: a clean archive result that meant nothing

StarScout's two signatures are the tests to run. The low-activity signature flags accounts whose only WatchEvent ever is this repository, plus at most one other event (such as a ForkEvent) in the same repository on the same day. The lockstep signature looks for clusters of at least 50 accounts and at least 10 repositories, where each repository got 25 or more stars from those accounts within one 30-day interval.

Spike B fell after the capture collapse. The archive came back clean, and that told me nothing.

Step 5: the usage cross-check

Forks, watchers, downloads and dependents are harder to fake together than stars alone, so they test whether the stars reflect use. At 2,850 stars, the published category averages imply these fork counts:

Downloads need care. The npm download API limits each query to 18 months of data, with nothing before January 10, 2015, and one test found a 27% undercount from relying on a single request. Pull the history in chunks and add them up. Dependents are the slowest signal to fake, because each one is someone else's code that relies on the package.

In the case, forks landed in the AI-tools band, and chunked downloads rose through both spike windows rather than only spiking alongside the stars. That is what later made the deal backable.

Step 6: the founder request that settled it

The founder is the only person who can pull the stargazer list now. On their own repository, the application/vnd.github.star+json header adds a starred_at timestamp to every entry, covering current stargazers only. Traffic (views, unique visitors, the top 10 referrers, the top 10 popular paths and clones) covers only the last 14 days, and nothing brings back day 15.

Hi [founder],

Your deck cites [figure] stars as of [deck date]. As part of diligence I've pulled the public daily star history, and I'd like to attribute two windows before I take this to partners:

- [window A dates]
- [window B dates]

Could you send:
1. A stargazer export for those windows with starred_at timestamps (the star+json format from the stargazers endpoint on your repo).
2. If either window is in the last 14 days, a short screen-share of Insights > Traffic: views, clones and referring sites.
3. Any traffic or referrer data you archived for older windows, and what drove each spike (launch post, release, talk, campaign).

This is standard for every dev-tool deal I look at, and it usually takes under an hour on your side.

Thanks,
[name]

Spike A was older than 14 days, so only the export applied. At the window level, its accounts looked like an ordinary population, and the launch explanation held. For spike B, the export showed a tight block of timestamps, and the window's zero-follower share was heading toward the 50 to 80% seen in flagged repositories. The founder could not attribute it. I marked spike B as flagged.

Step 7: the case's range and verdict

The high estimate is the live count minus spike B's stars from flagged accounts. The low estimate is the live count minus all of spike B's stars. The gap between the deck and the live count already sits outside both. The verdict was inflated but backable: the stars were dented, but usage held. The memo carried the range, both dates, the capture rate and the founder's evidence.

Who to call when a launch curve needs calibrating

Developer advocates who have run launches are the best calibration available, because no published day-level threshold says what a real launch spike looks like. In Refolk's index of professional profiles, 300 people in the US and 34 in Germany hold Developer Advocate or Developer Relations titles. The US figure is a round number and may be a cap.

The two pools need different handling. The German pool is small and concentrated, and roughly a fifth of a sample was off-title, so check every profile. The US pool is big and spread out, so one or two calls with people at unrelated companies will give you independent views.

Finding people who have personally run a Hacker News or Product Hunt launch is a filter that job titles alone cannot capture. Refolk handles that as a plain-English ask across LinkedIn, GitHub and the open web:

Two lessons from running these searches. First, a zero result is about the filters, not the world. A query for US VC partners with an open-source dev-tool focus returned 0 in Refolk's index, and that reflects the filter combination, not an absence of such people, so loosen one constraint at a time. Second, the strongest single sign of real interest is people outside the founding team doing work on the repository. Asking Refolk for engineers outside the founding team who opened pull requests on the target repository in the last six months gives you a reference list the founder did not choose.

Fork-to-star baselines by category

The fork-to-star ratio is forks divided by stars. Organic repositories in the one published sample average 0.160, and suspected manipulation clusters average 0.053. The ratio shows whether starring turned into the next step of use. It fails when the category, or the way the software is distributed, changes what normal looks like.

Read this table with its limits in view:

• One sample, not peer reviewed. All of these baselines come from one journalistic sample of 20 repositories with 150 profiles each.
• The spread is real. Flask's fork-to-star ratio is 13.8 times Free Domain's.
• AI tools sit in between. At 0.124, the AI-tools average falls between the organic and manipulated averages, so a single cutoff misclassifies AI dev tools in both directions. Fraud and organic demand concentrate in the same hot category.
• Infrastructure has no published baseline. If the deck is an infrastructure tool, say that in the memo and lean harder on downloads.
• Forks miss registry users. One critique points out that most software is distributed through a registry or a binary download, and neither shows up in forks.

The watcher-to-star ratio is the number of accounts subscribed to notifications (subscribers_count) divided by stars. It is a weaker signal but a useful second line: Flask sits at 0.03 and Free Domain at 0.001.

Union Labs shows why rankings are not diligence. It was ranked first on the ROSS Index for a quarter, with 54.2x star growth and 74,300 stars, and StarScout's analysis flagged 47.4% of its stars as suspected fakes.

How this audit goes wrong

Most errors in a star audit come from reading the absence of evidence as evidence, in one direction or the other. These are the eight failure modes I check for. Each one names a signal that lies and the check that catches the lie.

1. Reading the deck-versus-live gap as fraud. The history endpoint drops stars that were later removed, so a purged campaign vanishes from the curve on the day it was created, and ordinary unstars look the same. Check: compare the date of the deck figure with today's count before you read the curve, and carry the gap to the founder request.
2. Running the archive test on recent windows. At 10 to 20% capture, a real 50-account cluster shows up as about 5 to 10 accounts and falls below StarScout's thresholds, which gives you a false "clean". Check: compute the capture rate for the window and write it down next to the result.
3. A launch spike that looks bought. Launch-day stars arrive in single-day bursts, just like purchases. Check: match the spike to the date of the launch post, and look for a referrer spike if traffic data is still inside its 14 days.
4. Low-activity false positives. Real users who star once and go quiet fit the signature, and StarScout's authors note that fake stargazers' profiles are not distinct from average GitHub users. Check: flag at the window level only, never account by account.
5. Misreading the fork ratio. Registry and binary distribution never shows up as forks. Check: compare the ratio against the right category and against chunked downloads.
6. Aged purchased accounts. In one flagged sample, the bought accounts were not newly created: their median age was over 1,000 days. Dagster's fake-account rule (created after a recent cutoff year, under one follower, following no one, no public gist, four or fewer public repos) misses them. Check: do not treat account age as a clean signal.
7. Stale founder evidence. Traffic older than 14 days cannot be recovered, so a screen-share cannot cover an older spike unless the founder archived the data. Check: send the request the day you see a fresh spike.
8. Undercounted downloads. A single npm request silently truncates, and one test found a 27% undercount. Check: pull in chunks of 18 months or less.

The most important point in this section is that the public data now hides cheap fraud and shows expensive fraud. Cheap batches mostly drop out of the curve within a month. Premium stars survived a month untouched in the Dagster test. So any spike still visible is either real or bought at the premium end, and only the founder's starred_at export can tell those two apart.

Stating the organic range and the verdict

The deliverable is a range and one of three verdicts: credible, inflated but backable, or misrepresented. A point estimate claims a precision this data does not have. The range is built from the live count, never from the deck figure.

• Organic high = live count minus stars from flagged accounts in flagged windows.
• Organic low = live count minus all stars in any spike window still unexplained after the founder request.
• Outside both = the gap between the deck and the live count, reported separately with both dates.

What each verdict means in practice:

• Credible. Every spike has an explanation, ratios sit inside the category band, and the deck figure is close to the live count for its date.
• Inflated but backable. At least one window is flagged or still unexplained, but forks, downloads or dependents show real use. StarScout only labels a repository a fake-star campaign when the all-time fake share exceeds 10% and at least one month has more than 50 fake stars making up over half of that month's stars. I borrow its 10% line as the point where "inflated" belongs in the memo.
• Misrepresented. The deck figure materially overstates the evidence, usage does not back the stars, or the founder declines to share evidence the founder can easily pull. A refusal is itself a finding.

StarScout's evaluation table, in Section 3.4 of the paper, reports how the detector performed, but I have not verified its false-positive rate. Read that section yourself before you quote the method's error rate to partners.

Before the memo goes to partners

Run this list before the verdict goes anywhere, then put the founder request on a clock. Most audits that go wrong skip the capture rate or miss the 14-day window.

To keep the method current, re-check three things before each audit, because each one has changed before:

• Archive capture rate. Check the public capture-rate issue on GH Archive's repository (issue #320) and your own window's ratio. If capture recovers, the archive test becomes evidence again for recent windows.
• Unstar support. The history endpoint's documentation states that unstars are not recorded. If that changes, the deck-versus-live gap becomes something you can read from outside.
• Registry limits. Confirm the npm download API's per-query window before you chunk your pulls.

For a deal you expect to follow, pull the daily curve again each quarter. A spike that fades from the active-star curve within a month or two is the cheap-fraud signature, and it will be in your records rather than only in the founder's.