We went looking for what stalled projects have in common. It is almost never the code, and it is almost always visible three weeks before the last commit.

The Muster Team

Research

We asked four hundred people to point us at a project they had stopped working on, and to tell us when they thought it died. Then we compared their answer to the activity trail. The two dates rarely matched, and the gap is the interesting part.

Projects stall before they stop

On average the last real commit came nineteen days before the date people named. In between there was activity, but it was maintenance: dependency bumps, README edits, a config tweak. Motion without direction is the clearest early signal we found, and it is easy to miss from the inside because the commit graph still looks green.

The common causes were unglamorous

The most frequent one was an unfinished decision. Not a hard technical problem, but a fork in the road that never got closed: which auth provider, which pricing model, whether to rewrite the importer. Work continued around the decision until there was nothing left to do that did not depend on it.

Second most common was a broken local setup after time away. Third was losing the thread on what was left to do, which is a documentation problem wearing a motivation costume.

What actually restarted them

Of the projects that came back to life, most restarted with a single small merged change rather than a plan. The plan came after. That matches what we see in scores: cadence recovers first, and everything else follows it.

How we counted

We took the last merged change as the stall date rather than the last push, because pushes kept happening long after the work had stopped. Branches got created, dependencies got bumped by bots, READMEs got tidied. None of it moved the project, and all of it made the repository look alive.

We excluded anything a person told us was finished on purpose — roughly one project in nine. From the outside those look identical to stalled ones, which is a limitation of every signal we have.

On average the last real commit came nineteen days before the date people named. The project had been over for almost three weeks before anyone noticed.

The three-week gap

Nineteen days is long enough to matter and short enough to catch. Inside that window people still remember the decision they were stuck on, the local setup still works, and the branch still merges cleanly. After it, all three stop being true at roughly the same time, which is why restarting feels so much harder than continuing.

That is the whole argument for a page that tells you where you stand before you think to ask. Not because a score fixes anything, but because the window where a nudge still works is measured in weeks and nobody is watching it.

What did not predict a stall

Stars, forks and watchers predicted nothing. Neither did the language, the framework, or whether the project had tests. Team size barely mattered once we controlled for how often anyone merged anything.

The one surprising negative was detailed roadmaps. Projects with a written multi-month plan stalled slightly more often than projects without one. We do not think the plan causes the stall. We think writing the plan is often the last enthusiastic act, and the plan is what is left behind when the enthusiasm goes.

What we changed because of it

We moved the alert threshold from thirty days to fourteen, and we stopped counting bot commits toward cadence entirely. Both changes came straight out of this data, and both made the score less flattering for almost every project we track, including our own.

Written by