GitHub launched a star-history endpoint that returns aggregate weekly and daily counts, cutting requests and reducing database load.

GitHub said it has replaced a stargazer-based workaround with a purpose-built history endpoint that returns aggregate star trends without exposing individual identities. The change matters because maintainers use star history to gauge whether a release, launch or event changed a project’s trajectory, while GitHub said the older approach was being abused for data collection and was also expensive to serve.

In an Oct. 14, 2026 engineering post, GitHub said the new repository star history API can return up to 30 weeks of daily star counts in a single request, with no identities attached. GitHub said the endpoint filters stars by time before counting them, rather than counting first and trimming the response later, which it said reduces database work.

The company said the previous GET /repos/{owner}/{repo}/stargazers endpoint was designed to list current stargazers, not to act as a historical event log. Because stars are removed when users unstar a repository, the model does not preserve a complete history of past starring and unstarring activity. GitHub said tools had been reading pages of stargazer records and discarding the usernames to reconstruct a curve from timestamps alone.

GitHub said the original endpoint created two issues. First, identities were available for bulk collection, which it said led bad actors to scrape public stargazer lists for spam and phishing campaigns. Second, highly starred repositories could force the database to process many thousands of entries to return a single page.

Source link