How do you see who starred your GitHub repo?

Every public repo has a built-in stargazers page. Two ways to reach it:

The click path. Open the repo’s main page. In the row of buttons at the top right you will see Watch, Fork, and Star, each with a count next to it. Click the number next to the Star button (the count itself, not the star icon, which would star or unstar the repo). That opens the stargazers list.

The direct URL. Append /stargazers to any repo URL. The pattern is github.com/OWNER/REPO/stargazers, so a repo at github.com/acme/rocketdb keeps its stargazers at github.com/acme/rocketdb/stargazers.

This works for any public repository, yours or anyone else’s, and you do not need to be signed in. GitHub treats the star list as public data, the same as the repo itself. If you are researching a competitor’s repo instead of your own, the exact same page and the exact same API routes below apply.

The page shows each stargazer’s avatar and username, ordered newest first. That ordering is the one genuinely useful feature: the top of page one is whoever starred most recently, so a quick glance after a launch or a Hacker News spike tells you who just arrived.

Everything else is missing. On the stargazers page you get:

No dates. GitHub records exactly when each star happened, but the web page never shows it. You cannot see whether a star landed yesterday or three years ago.

No emails, no company, no role. The list is usernames. To learn anything about a person you have to click through to their profile, one at a time.

No sorting, searching, or filtering. Newest first is the only order. There is no way to search the list, filter by anything, or jump to a specific person.

No export. There is no download button. Browsing a 5,000-star repo means clicking Next through more than a hundred pages.

So the page answers “which usernames starred this repo” and nothing more. For the two questions people usually mean when they ask “who starred my repo” (when did they star, and who are these people), you need the API and then enrichment.

The REST route is GET /repos/{owner}/{repo}/stargazers. By default it returns plain user objects, which is no better than the web page. The trick most answers skip: send the application/vnd.github.star+json media type in the Accept header and each entry gains a starred_at timestamp alongside the user.

The quickest way to try it is the gh CLI, which signs the request with your logged-in account automatically:

gh api "repos/acme/rocketdb/stargazers?per_page=100" \
  -H "Accept: application/vnd.github.star+json"

The same call with curl, using a personal access token:

curl -H "Accept: application/vnd.github.star+json" \
     -H "Authorization: Bearer YOUR_TOKEN" \
     "https://api.github.com/repos/acme/rocketdb/stargazers?per_page=100&page=2"

Each item in the response looks like { "starred_at": "2026-07-01T09:14:00Z", "user": { "login": "dev-priya", ... } }. Pagination is the standard GitHub pattern: per_page goes up to 100 and you walk pages with the page parameter or the Link response header.

One practical note on auth: unauthenticated calls are capped at 60 requests per hour, which runs out fast when every request returns at most 100 people. With a token you get 5,000 requests per hour, enough to page through most repos comfortably.

Combining gh api --paginate with a jq expression gets you a spreadsheet in one command:

gh api "repos/acme/rocketdb/stargazers?per_page=100" \
  -H "Accept: application/vnd.github.star+json" \
  --paginate \
  --jq '.[] | [.user.login, .starred_at] | @csv' > stargazers.csv

That walks every page and writes one row per stargazer with their username and the moment they starred. A 10,000-star repo is 100 requests, well inside the authenticated rate limit, and takes under a minute.

This is already a real upgrade over the website. Sorted by starred_at, the CSV shows your star growth over time and tells you exactly who arrived during a launch week. If usernames plus timestamps are all you need, stop here: the free API route answers it fully.

Being honest about the ceiling saves you a wasted afternoon:

The 40,000 cap. GitHub’s REST pagination for this endpoint stops at page 400. At 100 per page, that is 40,000 stargazers, and requests beyond it return an error rather than more data. For bigger repos the only route GitHub offers is the GraphQL API’s cursor-based crawl, which fetches 100 at a time in strict sequence, so a 200,000-star repo means two thousand dependent requests you cannot parallelize.

It is a snapshot, not a feed. The list reflects the current state. Nobody appears as “unstarred”; if you want to catch people leaving, you have to export on a schedule and diff the files yourself.

You still only have usernames. This is the big one. The export answers “which accounts starred and when.” It does not answer the question that matters for a maintainer or a founder: who are these people? Which companies do they work at? Which ones match the audience you are building for, and which ones left a public way to reach them? A star from sam-codes could be a hobbyist, a student, or the platform lead at your ideal customer, and the CSV cannot tell you which.

Manually, you click each username and read the profile: name, company, location, bio, links, and a public email if the person published one. That works for twenty people. At two thousand it is a week of clicking, and you still end up copying rows into a spreadsheet by hand.

This is the part WarmStars automates. Paste a public repo URL and one scan turns the whole stargazer list into named profiles: name, company, role, location, social links, and a public email where one exists. Every email carries a confidence tier (verified, high, medium, or likely) so you know how much to trust each row before you use it. You can filter by company or role, sort by how recently each person starred, and export to CSV.

It is built to stay on the right side of the line: public data only, a do-not-contact list that is honored on every scan and export, and no sending. WarmStars hands you the list; the outreach stays in your tools and under your name. If that is where you are headed next, the follow-up guides on finding a stargazer’s email and turning stars into customers pick up from here, and there is a dedicated page on how open source maintainers use the same list to understand their community.

The free plan covers two scans a month with no credit card, which is enough to see your own repo’s list enriched end to end. Paid plans start at $39 per month if you outgrow it; the full breakdown is on the pricing page.