Method
Maintenance status
Every listing page says whether the software is maintained, at risk or abandoned, and prints the measurement it rests on beside it: the date of the last release, or for a hosted server the last commit, and the date that was read. Where no such date is on record, it says not measured. It never guesses.
The states
- MaintainedThe last release, or for a hosted server the last commit, was 180 days or fewer before the check.
- At riskThe last one was 181 to 365 days before the check, and nothing newer was on record when it was read.
- AbandonedNothing for more than 365 days before the check, and nothing newer on record when it was read. 365 days is the silence the publisher check already treats as dormant.
- Not measuredNo release or commit date is on record for the listing, or the only one on record cannot rule out a later release. Never a guess.
Days are whole days from the release or commit to the check, rounded down. A date that is only known to be a release, with a later one possibly unrecorded, can prove maintained when it falls inside 180 days and proves nothing otherwise, so it never makes a listing at risk or abandoned.
Where the dates come from
- npm, 794 listings
- The nightly publisher check reads each package's whole publish history from the npm registry, a slice a night, reaching each package about once every ten nights, and records the most recent publish of any version. Until it reaches a package, two records stand in, both as dates that can only prove maintained: the publish date the weekly version refresh recorded for the version a listing pins, and the dated releases in the publisher check's own findings.
- PyPI, 133 listings
- The newest upload across every release, read from PyPI when the listing's version was pinned.
- Hosted servers read from a repository, 67 listings
- The commit the listing pins, which was the head of the default branch when the repository was read, and its commit date.
Why not the catalogue's own date
Every listing carries an updated date, and for npm it cannot stand in for a release. Read against the npm registry on 30 September 2026, 9 of a 40-listing sample carried an updated date that was not the publish date of the version the listing pins, in each case later. A status built on it would have called packages maintained because of when this site read them. For PyPI and for hosted servers the date is the measurement itself: on the same day every PyPI listing matched its upload history, and every hosted listing with a recorded commit matched that commit's date.
The catalogue now
Of the 994 listings, 200 carry a measured date in the catalogue itself, and their states, each as of the date it was read, are: 149 maintained, 51 at risk, 0 abandoned. The 794 npm listings take theirs from the nightly record, shown on each listing page.
What this does not cover
- Quality or safety. It measures release activity and nothing else; the rubric and the findings are where safety is read.
- A finished package. Something small that does one job can go a year without a release and be fine; abandoned says nobody has published, not that anything is wrong.
- Who is behind a release. A new release can come from a maintainer returning or from somebody else in their account, which is what the publisher check's dormancy finding is for.
- Other branches and other channels. A commit date is set by whoever makes the commit, only the default branch is read for a hosted server, and a pre-release counts as a release.
- Anything after the check. Each status holds as of the date printed beside it.