For open-source maintainers, the "star" has long been the primary metric of a project’s health and trajectory. By analyzing the historical curve of these stars, developers can determine if a specific release, a major announcement, or a community event successfully moved the needle on adoption. However, the mechanism used to retrieve this data—the GitHub API—was never intended to function as a high-volume historical analytics tool. This fundamental misalignment between purpose and design eventually created a performance bottleneck and a privacy liability.
In response, GitHub has unveiled a new, purpose-built endpoint designed to provide aggregate star growth data while eliminating the privacy risks associated with exposing individual user identities. This transition marks a significant shift in how the platform manages developer data, moving away from identity-heavy responses toward efficient, time-based aggregation.
The Problem with the Original Design
The legacy GET /repos/owner/repo/stargazers endpoint was originally engineered to answer a singular, simple question: "Who has starred this repository?" To facilitate this, the endpoint returned a paginated list of user identities. For developers interested in trends, this meant the only way to reconstruct a growth chart was to scrape these lists, extract the timestamps, and discard the usernames.
Over time, this design created two distinct issues. First, it exposed user identities in bulk, inadvertently creating a treasure trove for bad actors. Scrapers began harvesting these lists to facilitate spam and phishing campaigns, forcing GitHub to address the vulnerability by restricting access to stargazer lists to repository administrators and collaborators.
Second, the technical architecture was fundamentally inefficient for historical analysis. Because the endpoint was designed to return people, not data points, the database was forced to process thousands of entries just to render a single page. On highly starred repositories, this led to massive overhead. The system often had to count every star in a repository to determine pagination, even when the user only requested a small subset. In the week leading up to the access restrictions, nearly 37,000 of these count queries were so resource-intensive that they triggered performance logging, with thousands being forcibly terminated by database safeguards to prevent system-wide timeouts.
Engaging with the Maintainer Community
The decision to restrict access to raw stargazer lists initially caused significant disruption for third-party tools, such as the popular star-history.com. While the privacy rationale was clear, the removal of access broke the workflows of many developers who relied on these tools to track their project’s progress.
Recognizing this, GitHub’s engineering and community teams initiated a dialogue with tool builders to understand their actual requirements. The feedback was consistent: maintainers did not need to know who had starred a project; they needed the "curve." They required a signal of interest to compare activity across different periods or to measure the impact of a launch.
"When the API change disrupted Star History, users rallied around the project," says Tianzhou Chen, a maintainer of star-history.com and co-founder of Bytebase. "GitHub’s Community team listened and connected us with product engineering, who dug into our use case and worked alongside us to design a purpose-built endpoint. A difficult situation became a constructive collaboration between GitHub, Star History, and the broader community—ultimately leading to a better solution."
This collaboration proved that identity was not a core requirement of the contract, but rather a byproduct of the original API design. By decoupling the "who" from the "when," GitHub was able to build an aggregate endpoint that provides exactly what the community needs at a fraction of the cost.
Engineering a More Efficient Path
The core challenge for GitHub’s engineers was to design an endpoint that returned historical trends without requiring the database to perform a full scan of every star in a repository’s history. Initial experiments focused on returning historical timestamps without user identities. While this solved the privacy concern, it failed to resolve the underlying performance issues. API consumers would still be forced to paginate through thousands of individual records to build their own aggregations, a process that was both slow and computationally expensive.
The team then explored an aggregation model where the database would group stars into daily or weekly buckets before returning the results. However, they discovered that if the pagination occurred after the grouping, the database would still be forced to perform a full scan of every star record before applying the filter. For a massive repository like react/react, which boasts over 250,000 stars, this would still require processing millions of rows for every request.
The final solution implemented by GitHub reverses this logic. The new endpoint paginates data by calendar week and applies an indexed created_at filter before performing any aggregation. By narrowing the dataset to a specific time range first, the database only processes the records relevant to the requested period.
This approach is transformative for performance. Instead of making thousands of requests to reconstruct a history, a tool can now retrieve up to 30 weeks of daily star counts in a single call. For large projects, this reduces the number of required API calls by several orders of magnitude. Furthermore, the database only examines the relevant records once, rather than re-counting the entire history with every page load. This new endpoint now aligns with other repository metrics, such as the weekly commit activity endpoint, ensuring a consistent experience for developers across the GitHub ecosystem.
Broader Implications for Platform Performance
The process of building this new endpoint also highlighted other areas where GitHub’s infrastructure was performing unnecessary work. By identifying the pattern of "counting on demand," engineers were able to optimize other parts of the platform. For example, the stargazers page on GitHub.com was updated to utilize cached star counts rather than live queries. This change alone reduced the number of slow, resource-heavy queries from hundreds per week to zero.
This development serves as a case study in the evolution of API design. By moving from a general-purpose, identity-focused list to a specialized, aggregate-based trend tool, GitHub has managed to satisfy two competing priorities: securing user privacy and providing developers with the actionable insights they need to grow their projects. The success of this transition, which was heavily informed by direct communication with the maintainer community, underscores the importance of understanding the intent behind API usage rather than simply managing the data it exposes.
The result is a more resilient and performant architecture. While highly dense weeks with an unusually high volume of stars remain a natural scaling challenge, the overall load on the system has dropped significantly. By restricting the scope of each request to a defined time range, GitHub has effectively future-proofed its star tracking, ensuring that as repositories continue to scale, the tools used to monitor their success remain fast, reliable, and respectful of user data.
