Blank Star History Chart? Fix Your Repo

If the Star History image in your README turned into a blank box, an error badge, or a suspiciously empty curve overnight, you are not imagining it.

GitHub changed who can read stargazer timelines. Charts that depended on a third-party server freely scraping “who starred when” stopped working for a lot of public repos. This post is the short version: what to do when the broken chart is for a repository you admin.

If you want the policy detail, read GitHub Restricted Stargazer Data. Here we stay on the fix.

Quick diagnosis

You probably hit this change if:

The embed used to work and went blank around GitHub’s June 2026 access restriction
The chart was served by a public Star History-style URL for a repo the service does not administer
Opening the same repo as a collaborator still shows stars in the GitHub UI, but the third-party SVG does not

What still works in principle: your own repos, when the tool uses your authorization (or a token that can actually read that repo’s stargazer list).

What does not work anymore as a free public trick: paste any famous repo into a URL and get a live timeline.

Fix it for a repo you control (no PAT scavenger hunt)

You do not need to dig through GitHub Settings → Developer settings → Personal access tokens, invent scopes, copy a secret into a README, and hope you never leak it.

On GitHubCard the path is closer to normal app auth:

Open the repo card editor for the repository you manage.
Sign in with GitHub. If we ask for extra repository access (public_repo), accept it. Login scopes alone are no longer enough for the stargazer timeline.
Add or refresh the Star History widget while that authorization is active.
Publish the card and replace the old README / site embed with the new image URL.

We store an aggregate snapshot on the widget (dates and cumulative totals, not individual stargazer identities). Public viewers then read that snapshot. They do not need our server to keep re-fetching GitHub as if it were still a public dataset.

Why this is fewer clicks than a classic token flow

Older “bring your own token” tools made sense when anyone with a PAT could read public stargazer lists. After the restriction, that model mostly means: create a token with the right access, paste it somewhere, babysit rotation, and still only cover repos that token can see.

If your goal is “show growth for my project in a README,” authorizing the GitHub App / OAuth a couple of times is the boring path that matches how the API works now.

What we will not promise

We will not draw a fake curve for a repo you cannot access.
We will not paper over the restriction with scraped mirrors just to recreate “chart any repo on the internet.”
We will not ask you to stick a high-privilege token in a public markdown file.

Other repo card pieces (title, metrics, languages, commits, and so on) still work for public repositories the way they did before. Only the star timeline got picky about permissions.

Bottom line

Blank Star History embeds are usually a policy change, not a flaky CDN day. For a repository you admin, authorize once, capture the timeline, publish the card, swap the embed.

Start here: GitHub repo card generator.

GitHubCard Team