See how far behind every project is, before it breaks.

A libyear is one library, one year behind its newest release. If your project uses a version of a library published in March 2021 and the newest version came out in March 2025, that library is four libyears behind. Add up every library in a project and you have the project’s number.

Ten libraries each a year behind is ten libyears. So is one library ten years behind. Zero means everything is current. The measure was proposed by researchers in 2015 and is used by Renovate, Sonatype and others because it answers a plain question: how much of the world moved on without you?

There is no universal line, and anyone who gives you one is guessing. A project under a libyear or two is being looked after. A few is normal for something in steady use. Tens mean an upgrade project is waiting, whether or not anyone has scheduled it.

The more useful question is the direction. A number that creeps up every month is a project nobody is maintaining; one that drops after each sprint is one somebody is. The dashboard shows both the level and the trend, and lets you set a threshold per client so you hear about it when a project crosses the line.

Because it stops being true quietly. Old versions stop receiving security fixes, so a vulnerability found next year is fixed only in a version you are not on. The language runtime it depends on reaches its end of life. And the longer the gap, the bigger the jump when you finally have to move.

Small updates done often are cheap: a minor version rarely changes how anything works. Skip them for two years and the same libraries are now several major versions ahead, each one having removed or renamed something your code uses. That is the point at which an afternoon’s update becomes a month’s project, usually discovered when something else forces it.

Needs attention counts libraries with a published vulnerability that is critical or high and, for the critical ones, confirmed by more than one source, so a single automated report does not page you. Quick wins are vulnerabilities a small update would close, with no major version to cross: the best rows on the page, because they are real security fixes that cost an afternoon.

Health is 0 to 100, combining how far behind the project is, whether its libraries are still maintained, and what is dangerous today, with hard caps: an end-of-life runtime caps it at 49, an open critical vulnerability at 59. The grade is the same number as a letter: A from 85, B from 70, C from 55, D from 40, F below that. The dashboard shows each part beside the total so the number can be argued with.

Two kinds of file. The manifest (package.json) lists what your project asked for. The lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml or bun.lock) records exactly what was installed. It also reads Dockerfiles and CI workflow files, because container images and CI actions are dependencies too. It never reads your source code and never clones a repository.

Private package names, the ones that would tell an outsider what your internal systems are called, never leave the system. The security page lists every file path it can fetch.

Those tools open a pull request for each outdated library in each repository. They are good at that, and they work fine alongside this. What they do not give you is one screen across every repository you look after, a number you can put in front of a client, or an order to do the work in.

Most teams with forty repositories also have four hundred open bot pull requests nobody reads. The problem was never knowing that something is outdated. It is knowing which project to deal with first.