Here are the numbers for Yad, my open-source browser automation agent, as of today. 79 unique clones. 2 GitHub stars. 0 forks. 4 users on the Chrome Web Store. 11 unique visitors to the repo page.
I am not writing this because those numbers are impressive. They are not. I am writing this because until today I had no idea what they were, and neither did anyone looking at the README.
The repo went up on 2026-08-24. GitHub's traffic Insights only shows a rolling 14-day window, and the repo is 10 days old, so what I am looking at is basically the whole life of the project so far, not a curated slice.
Total clones over that window: 219, from 79 unique cloners. Total views: 47, from 11 unique visitors. There is one day that stands out, 2026-08-29, with 85 clones from 24 unique cloners in a single day. I do not know what caused that spike. Git clone traffic generally does not carry a web referrer, so GitHub cannot tell me either, and I am not going to guess and pass off a guess as an explanation.
What little referrer data exists is thin. yadagent.com sent 17 visits from 3 unique visitors. github.com itself sent 15 visits from 4 unique visitors. alternativeto.net sent 1 visit from 1 visitor. That is the entire attributable list. Almost everything else has no referrer at all, which is apparently normal for clone traffic and not a sign that my tracking is broken.
Separately from all of that, the Chrome Web Store has its own live counter, and right now it says 4 users. That is a smaller number than the clone count, and it is a different kind of number. Clones can be curiosity, CI, a script, someone checking it out and moving on. The Chrome Web Store count is the closest thing I have to actual people running the actual extension, not just people who cloned the repo to look at the code. 4 is the honest number.
I also checked npm out of habit, since a companion package would make sense for this kind of tool. There is no package for this project on npm under any name I tried. The name "yad" is already taken, by an unrelated, older Express routing library from a different author. Not me, not this project.
None of this was visible anywhere. Before today, the README had a CI status badge and an MIT license badge. That was it. No stars, no forks, no install count, nothing that told a visitor whether anyone else had ever touched this thing. I built the extension, wrote the docs, wired up CI, and never once put a number on the page, or even looked at the numbers myself.
So today I fixed that. The README now has four more badges: Chrome Web Store install count, live. Chrome Web Store version, live. GitHub stars, live. GitHub forks, live. Small numbers, but they are on the page now, and they update themselves instead of going stale the way a hand-typed number would.
While I was in there making that change, I nearly caused a different problem. A routine git add -A picked up 38 other untracked files sitting in my working tree, including a 91 MB Windows installer and several Chrome Web Store upload zips. None of it was in .gitignore, because I had never needed it to be until it was sitting next to a commit I was about to push. GitHub warns above 50 MB and refuses pushes above 100 MB, so that installer was one push away from breaking things for whoever hit it first. I caught it before it went anywhere, backed it out, and fixed the .gitignore in the same pull request.
Two things happened the same day, and they are really the same mistake. I built the thing and never put a number on its own front page, and the exact same not looking almost let a 91 MB installer ride into git history unnoticed. First, small numbers are still numbers, and a page with none on it looks emptier than it is. Second, git add -A on a working tree you have not audited in a while is a habit worth breaking before it breaks a push.
If you have a repo you have not looked at the Insights tab for, go look. You might be sitting on a number you have never written down anywhere.
Top comments (0)