Thanks for the nudge, I’d been meaning to write about this here.

The downloads counts in the npmjs.org site work like this:

1. Every day at a specific time, an npm-logbot script runs, which parses the CouchDB log files for any 200 Ok response to a pkg-version.tgz file.
2. The numbers are tallied up for each package and day, and then PUT into the downloads database.
3. To get the number of downloads per day/week/month, the npm-www code makes a request to a CouchDB view that sums up all the counters.

As the database grew, the time required to generate and load that data kept increasing gradually. Eventually it reached the point that it took several seconds for the front page of the website to be available on a new worker, which is several seconds too long.

Complicating matters further, tarballs are now served by the Fastly CDN, so the log data comes in a completely different form.

All of the original CouchDB and Fastly log files are backed up, and once we figure out a more reasonable way to store and query the stats we have, we’ll bring back download counters and hopefully even more interesting stuff.

I think everyone would agree that operational stability is more important than vanity statistics, so that’s the first order of business. However, downloads is one of many important metrics of a module’s popularity and relevance, so our users care about it. From my personal interest, that “up and to the right” graph is a huge motivator for companies to invest time, attention, and money in npm. It’s not the first thing on my todo list, but I have plenty of selfish reasons to make sure we get to it soon.

Thanks for your patience.