A health score is a compression of a lot of activity into a single number, and every compression throws something away. The useful question is not whether a score is perfect, but whether you can predict what moves it. So here is the whole recipe.

The four signals

Cadence looks at the gaps between meaningful commits, not the count of them. A project that ships something small every few days scores higher than one with a burst of forty commits and three quiet weeks either side.

Freshness measures how long the newest work has been sitting unmerged or undeployed. Review latency measures the time between a change being ready and someone looking at it. Drift tracks the distance between your default branch and whatever is actually running.

What the score ignores

It ignores lines changed, because volume is not progress. It ignores issue counts, because a healthy project and an abandoned one can both have a tidy backlog. It ignores anything it cannot read from a provider, which means it will never guess at how the team feels.

Reading the number

Treat it as a smoke alarm, not a performance review. A score that drops twenty points in a week is telling you something specific and recent, and the panel underneath it will name which of the four signals moved. A score that sits at seventy for a month is telling you the project is fine and you can look somewhere else.

Why one number

We tried showing four. People averaged them in their heads, badly, and then argued about the weighting. A single number is a worse description of reality and a better tool, because it produces the same answer for everyone looking at the same project.

The weighting is fixed and public: cadence forty, freshness twenty-five, review latency twenty, error load fifteen. We do not let you tune it. A score you can tune is a score you can talk yourself into, and the first thing anyone tunes is the signal they are currently failing.

How the bands work

Above eighty is healthy — the project has a rhythm and nothing is stuck. Sixty to eighty means one signal is dragging, usually review latency. Forty to sixty means two have gone soft at once, which is the point where projects tend not to recover on their own. Below forty the project is stalled, whether or not anyone has said so out loud.

The bands are deliberately wide. A three-point move is noise, and we do not send you anything for noise.

A score that drops twenty points in a week is telling you something happened. A score that sits at sixty for a month is telling you something did not.

Where the score is wrong

It is wrong about projects that are finished. A library that does exactly what it should and needs no changes will score badly forever, because every signal we have is a measure of motion. Archive those, or accept the number and ignore it.

It is wrong about work that happens outside the repository. A week of user research, a rewrite planned on a whiteboard, a migration blocked on a vendor — none of that is visible to us, and the score will drop as though nothing happened. That is the honest cost of only reading what providers expose.

It is wrong, briefly, about projects that have just changed shape. Splitting a monorepo or moving hosts resets the history we compare against, and the first fortnight after a move is not comparable to the fortnight before it.

What we will not add to it

We will not add a per-person score. The signals we collect could produce one, and the moment it exists the number stops describing a project and starts describing a colleague. That changes what people do with it, and none of the changes are good.

We will not add a signal we cannot explain in one sentence to the person being measured by it. That rule has killed more proposed inputs than any technical constraint, including three we had already built.

Written by