What can GitHub’s repo insights and analytics actually tell you?

Here's a thing most maintainers never clock: GitHub has been quietly keeping a dashboard on your repo the whole time. Open any repository, click the Insights tab up top, and you land at github.com/acme/rocketdb/pulse. But that tab is just a doorway. The real menu is the left sidebar, and it runs nine reports deep: Pulse, Contributors, Community Standards, Traffic, Commits, Code frequency, Dependency graph, Network, and Forks. Most of them are public, which surprises people every single time.

Pulse is your landing pad, and it is exactly what the name promises: a heartbeat. Pick a window, anywhere from the last 24 hours to the last month, and it rolls up what moved. Pull requests merged and opened. Issues closed and opened. How many contributors showed up. Think of it as a Monday-morning vibe check, not a microscope. Handy for a glance, thin for anything deeper.

Traffic is the one panel that feels like an actual analytics product. And it comes with a velvet rope.

You only see Insights > Traffic (github.com/acme/rocketdb/graphs/traffic) if you have push, meaning write, access. Try it on a stranger's public repo and the option just isn't there. No error, no explanation, it simply does not exist for you.

Four panels wait inside. Visitors gives you total page views and unique visitors. Git clones splits total clones from unique cloners. Referring sites ranks the top 10 places funneling people your way. Popular content ranks the top 10 paths they actually opened. Genuinely useful, right?

Here's the catch, and it's a big one: every panel covers the trailing 14 days and not a day more. GitHub throws out anything older. No archive, no scroll-back, no year-over-year. Want a longer memory? You build it yourself. Check on a cadence, or hit the REST API on a schedule and store the rows: GET /repos/{owner}/{repo}/traffic/views, /traffic/clones, /traffic/popular/referrers, and /traffic/popular/paths, all needing the same push access as the UI.

One more thing, and it matters for everything that comes later. Traffic is anonymized on purpose. Unique visitors get deduplicated, never named. You learn interest is climbing. You never learn whose.

Contributors (github.com/acme/rocketdb/graphs/contributors) paints a commit timeline plus a card per person, and you can flip the metric between commits, additions, and deletions. Slick graph. Read the fine print before you brag about it, though. It counts commits on the default branch only, ignores merge commits, and ties every commit to an account by the author's email. So commit under an email that isn't on your GitHub account? You vanish from the graph, or turn up as a ghost row nobody recognizes.

Community Standards (github.com/acme/rocketdb/community) isn't about usage at all. It's a hygiene checklist: Description, README, Code of conduct, Contributing guidelines, License, Security policy, Issue templates, and a Pull request template. Each line is a green check or an Add link. It measures whether your project looks looked-after, not whether a soul is using it.

Then come the momentum twins. Commits (.../graphs/commit-activity) is a weekly commit histogram. Code frequency (.../graphs/code-frequency) plots additions and deletions per week across the repo's entire life. Both are great for catching a burst of energy, or a long, telling quiet.

The Dependency graph (github.com/acme/rocketdb/network/dependencies) is read straight out of your manifests and lockfiles: package.json, requirements.txt, go.mod, all of them. It has two faces. Dependencies is what your project leans on. Dependents is the public repos and packages leaning on you, which is a rough-but-real proxy for how far your code has traveled. And that Dependencies side? It's the same graph powering your Dependabot alerts.

The Network graph (github.com/acme/rocketdb/network) draws the fork network, tracing how each fork's commits peel away from your default branch. The Forks list (.../network/members) just lines them all up. Put the two together and you can watch who copied your code to build something on top of it. The catch? You see it down to the account. A username. Not a person, not a company, not a reason.

Notice the pattern by now? Every single panel we've walked, at the bottom, is a number or a curve. That is the ceiling of built-in analytics, and it's a low one.

Your repo page flashes a star count and a public stargazers list (github.com/acme/rocketdb/stargazers). Sounds promising. Then you open it and it's usernames and avatars. No company. No role. No way to tell a weekend tinkerer from a staff engineer at exactly the account that would pay for your tool tomorrow.

So here's the unvarnished version. Traffic can tell you 4,000 people viewed rocketdb in two weeks and not name one of them. You can watch the star count climb for months and have zero clue which of those developers is a real buyer, sits inside a target company, or is even reachable. The signal is deafening. The identities are blank. And that blank is the whole problem.

Closing that gap, going from 'how many stars' to 'who starred it', is the entire job of founder-led sales. A star is a public raised hand: a real human liked your project enough to bookmark it. The frustration is that GitHub hands you the hands and hides the humans.

That's the exact spot WarmStars steps in, and only for repos you own. You give it a public repo, it walks the stargazers, and it hands them back as named developers with company, role, and a public email where one exists, sorted owner-first so the accounts that matter float to the top. Every email wears a plain confidence tier, verified, high, medium, or likely, so you know how hard to lean on it.

And here's the honest boundary, because you deserve it: public data only, do-not-contact respected, and it never sends a thing for you. What you get is a researched list of the actual people behind your stars, and what happens next is your call. The Insights tab shows you the shape of the interest. WarmStars shows you who's standing inside it.