Monitor GitHub repositories by keeping dated observations of explicit owner/repository identities. A Trending page can help discover candidates, but it is not a historical star-growth API. A current star count cannot tell you when every star was added.
Separate discovery from the repository snapshot
| Record | Purpose |
|---|---|
| owner/repository and repository ID | Keep the identity explicit across renames |
| observed_at | Define when the count was checked |
| stargazers_count | Retain the observed cumulative count |
| request status | Separate unavailable data from zero stars |
| previous snapshot reference | Make the comparison reproducible |
Compare like-for-like snapshots
Compute the difference only when the observations refer to the same repository identity. Preserve the original observation times; different intervals are different measurements. If a repository is renamed, moved or unavailable, resolve that event before interpreting a count change.
Use GitHub’s current repository endpoint and documented authentication/rate-limit rules for a repository snapshot. A SERP or Trending observation can add discovery context, but should not replace the repository record or be treated as evidence of all developer demand.
Check a small monitoring fixture
This is a reproducible monitoring design. It does not invent a GitHub Trending API, a customer success story or a measured API-cost saving.
- Store two synthetic snapshots for one stable repository ID.
- Add a rename that preserves the ID and an unavailable request with no count.
- Confirm that an unavailable snapshot is not converted into a star decline.
- Report the observation interval beside any calculated change.
Reference documentation: docs.github.com — /en/rest/repos/repos; docs.github.com — /en/rest/using-the-rest-api/rate-limits-for-the-rest-api.
