Open GitHub Insights and you get a wall of charts: commits per week, lines added and deleted, a ranked list of top contributors, a punch-card of when people work. It looks like a health dashboard. But if you're a founder, client, or investor trying to answer a simple question — "is this codebase in good shape?" — you can stare at those graphs all day and be no closer to an answer. That's not your fault. Those charts measure activity, not health.
The problem isn't GitHub Insights specifically; it's the whole category of activity dashboards. This is a look at what they actually show, why it doesn't answer the question you have, and what to read instead — the git history as a short list of questions worth raising, not a scoreboard.
GitHub Insights and similar dashboards show vanity metrics — commit counts, lines added or deleted, contributor rankings — that reflect how much activity is happening, not whether the work is healthy, and most are easy to game. To actually judge a codebase, read the questions its history raises: where knowledge is concentrated in one person, whether tests keep up with changes, and what looks unusual. Read history as questions, not charts.
What does GitHub Insights actually show you?
GitHub Insights is an activity dashboard. Its main views count things: how many commits happened per week, how many lines of code were added and removed, who the most frequent contributors are, and what times of day people push work. These are real numbers, and they're not useless — they can confirm that something is happening. But every one of them measures volume of activity. None of them tells you whether that activity is producing a healthy, maintainable product, and that's the gap.
Why don't those charts answer "is my project healthy?"
Because activity and health are different things, and the metrics are easy to game — usually without anyone meaning to. More commits can mean steady progress or thrashing on a problem nobody understands. A big spike in "lines added" can mean a real feature or a giant copy-paste that doubles your future maintenance. A ranked list of contributors tells you who is busy, but not the thing you actually need: whether one of them is the only person who understands something critical. These are what people call vanity metrics — numbers that look reassuring precisely because they go up, while saying nothing about risk.
What should you be reading instead?
The same git history that powers those charts can answer far more useful questions — you just have to ask different ones. Instead of "how many commits?", ask: is the knowledge for each critical area spread across people, or concentrated in one (the bus factor problem)? When features ship, do tests ship with them? How much work goes in without a second person reviewing it? Which parts of the code keep changing together in ways that suggest they're tangled? How much of this month was new work versus redoing old work? None of these are on an activity dashboard, and all of them are readable from the history.
Can I get this from GitHub Insights, or do I need something else?
Honestly, not from Insights — it isn't built to compute concentration of knowledge, review coverage, or whether tests move with features. You have two realistic options: have a trusted technical person read the history with these questions in mind, or use a tool built to do it for you. That second option is what PulseRepo does — it reads the git history of the repositories you connect and turns it into a short, plain-language list of the questions worth raising, so a non-technical stakeholder gets the read without needing a developer on call.
Isn't this just swapping one set of metrics for another?
No — and the distinction is the whole point. A metric hands you a number and leaves you to guess what to do with it; a scoreboard invites you to rank and judge people, which is exactly the wrong use of git history. The output here is different: a short list of questions to raise with your team — "why is all the payment code owned by one person?", "should this feature have shipped without tests?" — not a score, not a verdict, not surveillance. The history points at things worth a conversation; the judgment stays human.
Where do I start?
If you want to see what "history as questions" looks like in practice, the fastest way is to look at a sample report — a real, anonymized run showing the questions it surfaces. If you'd rather start with the thinking behind it, the broader guide on how to tell if your dev team is doing good work without being technical covers the same signals from a non-technical angle.