GitHub launches star history endpoint reducing requests from 2,500 to 24

GitHub has introduced a new API endpoint that provides repository star history as aggregate daily counts, eliminating the need to scrape individual stargazer identities. This change addresses both privacy concerns regarding spam and phishing campaigns and significant database performance issues caused by the previous method of reconstructing growth curves.

The Problem with Identity-Based Scraping

Previously, tools reconstructed star history by paginating through the GET /repos/{owner}/{repo}/stargazers endpoint, which returned individual user records and timestamps. For a repository like react/react with approximately 251,000 stars, building a full history curve required about 2,511 requests. This approach was inefficient and risky:

• Privacy Risks: Public stargazer lists were scraped for spam and phishing.
• Database Load: A pagination bug forced the database to count all stars for every page request. Nearly 37,000 slow count queries ran weekly, averaging 3 seconds each, with over 1,000 killed by safeguards.

New Design: Filtering by Time

The new endpoint shifts the processing model from filtering after aggregation to filtering before grouping. By translating page parameters into an indexed created_at range, the database processes only the specific weeks requested rather than scanning the entire current star set.

• Efficiency: For react/react, the full history now takes about 24 requests instead of 2,511. The database examines each star roughly once across the full history.
• Response Structure: Each request returns up to 30 weeks of daily counts. The response shape aligns with the weekly commit activity endpoint (GET /repos/{owner}/{repo}/stats/commit_activity).

Limitations and Learnings

While the new design significantly reduces load, it retains certain constraints. Calendar boundaries and removed stars affect the data, and exceptionally dense weeks can still produce slow queries. The key takeaway is that reducing response size does not automatically reduce query cost; the order of operations—filtering before aggregation—was critical to performance.