GitHub's star history API cut 2,511 requests to 24, but deleted stars vanish

GitHub has explained how it rebuilt star history, the charts that show how fast a repository gained stars: an endpoint that returns daily star counts without the identities of the people who starred, cutting the requests needed for the full history of react/react from about 2,511 to about 24. The catch, which GitHub spells out in an October 14 engineering post, is that the curve only counts stars that still exist today.

The change closes a loop that started when GitHub restricted its old stargazer lists to repository administrators and collaborators. Star history tools, which maintainers use to see whether a launch or release moved the needle, had been rebuilding their charts from those lists.

Why the old method was both leaky and slow

The previous endpoint returned pages of users, 100 at a time, each with the moment they starred. Tools stitched those timestamps into a growth curve. According to GitHub, the same list was being scraped by bad actors to collect usernames for spam and phishing.

It was also expensive. In one week before the restriction, GitHub logged about 37,000 slow count queries averaging nearly 3 seconds each, and more than 1,000 of them were cut off by database safeguards. Part of the cause was a pagination bug: every request counted all of a repository's stars to compute the page total, even when it returned only one page. After the restriction, stargazer requests reaching the database fell about 60% and time spent on the count query fell about 80%.

Filter first, then count

The new endpoint returns up to 30 weeks of daily counts per request, in the same shape as GitHub's weekly commit activity endpoint. Each page number maps to a date range on an indexed timestamp, so the database pulls only the stars from those weeks before grouping them. Asking for the next page moves further back in time.

GitHub says it rejected the obvious alternative of grouping everything and then slicing the result. For a repository with about 251,000 stars, that design would have touched roughly 6 million rows across 24 requests, because each request would reprocess every star. The shipped version looks at each star about once. The authors' summary of the lesson: a smaller response is not the same as a cheaper query.

What the curve cannot show

GitHub stores only the current set of stargazers. When someone removes a star, the record is deleted, so there is no event log to replay. A project that gained a burst of stars and later lost many of them will show the surviving stars at their original dates, not the spike and the drop.

There are smaller limits too. Results line up with calendar weeks rather than arbitrary windows, and an unusually busy week can still produce a slow query because the date filter caps the range, not the number of stars inside it. GitHub calls star history an approximate signal of interest rather than a precise measurement.

The endpoint itself went live in early September, and Star History, one of the best known charting tools, says it adopted it right away. The October post is the first detailed account of how it works and what it leaves out.