Healthy at Scale: What Chatwoot and Grafana Do Differently

Most big codebases score lower on health than small ones. In our data the median drops from close to a perfect 10 for tiny repos to about 7 past 100,000 lines. Chatwoot and Grafana are two of the exceptions. Among the 45 popular repos in our index with more than 300,000 lines of code, chatwoot ranks third on health and Grafana ninth, and among the 8 with more than a million lines of code, Grafana is second.

The clearest difference is file size: both repos keep most of their code in short files, and they keep the few long ones known. That is the pattern across the 45 repos in our index, and the rest of this post shows the numbers.

repowise's code health score (1 to 10) rates how likely a file is to cause bugs and how hard it is to change, using static checks plus git history; the repo score is the average across files, weighted by lines of code.

The scores

Until this week their repo pages showed 9.6 for chatwoot and 8.6 for Grafana, because our scoring engine used to count JSON, YAML and Markdown files, which always scored a perfect 10. Chatwoot has about 640,000 lines of JSON, mostly translation files for its dashboard, and they pulled its average up. On 6 October we re-scored every older index on code files only, and both pages now show the code-only score.

Both still sit near the top of the big repos in our index, where the median is 6.9.

Small files

For 29 of those big repos, the ones last indexed before 13 September like chatwoot and Grafana, I measured how much of the code lives in long files:

In the typical big repo, almost half the code sits in files longer than 500 lines. In chatwoot it's about a tenth. Grafana sits between the two, which is still well below the typical big repo for a codebase six times chatwoot's size.

The median file sizes look similar (46, 80 and 68 lines), so the difference is in the tail. In the typical big repo, more than a quarter of the code sits in files over 1,000 lines; in chatwoot it's 4% and in Grafana 16%.

File size and the score

Most of the checks behind a health score get worse as a file gets longer, and they tend to get worse together. Long files tend to have long functions, deep nesting and duplicated blocks. They also tend to be edited by more people for more reasons, so they change often and pick up more bug fixes. And I think a reviewer reading a 2,000-line file can't hold all of it in their head, so problems are more likely to survive review.

The score and the bugs line up in chatwoot: of its 20 lowest-scoring files, 14 had a bug fix in the six months before we indexed it.

Inside each repo

Chatwoot is a Rails app with a Vue dashboard, and it has a lot of tests: 43% of its code lines are in spec and test files. Its Ruby side (services, controllers and models) mostly scores above 9, and the hard parts are a few big Vue components. ReplyBox.vue, the message composer, is about 1,570 lines (1,329 lines of code) and is the repo's top hotspot, with 116 feature commits and 64 fix commits in its history. My guess is that most products have a screen like that, where every feature ends up, and chatwoot keeps the number of such files small.

Grafana is two codebases in one repo. The TypeScript front end in public/app is 875,000 lines and scores 8.8, while the Go back end is lower: pkg/services scores 7.3 and pkg/storage 6.2. I haven't checked whether that split is typical. My guess is that storage and API layers are where the hard concurrency and migration logic ends up, whatever the language. Grafana's top hotspot is pkg/services/featuremgmt/registry.go, the list of every feature flag, with 150 contributors and 210 feature commits. It's a registry, a kind of long file that reads fine and mainly costs merge conflicts, which I wrote about in the longest functions post.

Grafana also spreads ownership wider than almost any repo we index: its bus factor is 34, and no single person is the main author of more than 5% of files.

Habits to copy

You don't need a rewrite to move toward this. These habits fit what we see in the two repos:

1. List the files over 1,000 lines. They hold a lot of your code, and that list is your health plan.
2. Stop those files growing. When a feature would add to a 1,500-line file, put it in a new file next to it, because splitting an old file is hard and not adding to it is easy.
3. Split files by reason for change. If one file is edited by every feature (a composer, a router or a registry), split it so different features touch different files.

repowise's code health page shows the files dragging a score down, their size and how often they change. Paste any GitHub URL to see your own list.

Limits of these numbers

• Both repos were last indexed in August and have changed since. Repos indexed since 13 September score a little lower than older indexes of the same size, which may push chatwoot and Grafana up the ranking slightly.
• File size is the clearest difference I found, but I didn't control for language, age or team size, all of which also matter.
• "Test code" is matched by path (spec, test, e2e), so the 43% is approximate.

How we measured

The ranking uses every public repo in our index with 500+ stars and more than 300,000 lines of code, counting code files only: 45 repos, with scores from 6 October after the code-only re-scoring. The file-size table uses the 29 of them last indexed before 13 September: for each one I downloaded the per-file health scores from our public API, dropped data and docs files (JSON, YAML, Markdown, SQL, CSS and similar), and computed the file-size shares from what was left. Checked on 6 October 2026.