MetricHouse

Why it exists

Say you want to count sign-ups and sales in your app. Today you have three options, and none of them is simple:

• Pay for a hosted analytics service. It costs money, keeps your data, and the numbers show up late.
• Run your own analytics setup. That means running and maintaining several extra systems, such as ClickHouse, Kafka and Postgres.
• Use a monitoring library. Those need a separate collector server running next to your app.

None of them lets your own code ask “how many sign-ups so far today, across all my servers?” and get the answer right away.

MetricHouse is a small library you add to the app you already have, whatever it’s built with. It owns the collection and handles the hard parts: counting, grouping events into time windows, keeping live totals, and surviving crashes. Then it calls your code with the finished numbers on a golden plate.

From there, your system decides what to do with them. Store them in a relational database or a document database. Shape the tables however you want, and change that shape later if you need to. Send them somewhere else entirely. MetricHouse doesn’t care, which is why it fits into any tech stack. You keep your data, and there’s nothing new to run.

What it does

You define what to track, like sign-ups or how long checkout takes. Your code records each event as it happens. MetricHouse groups events into time windows, such as one per minute, adds them up, and regularly passes the totals to a function you write. That function is the only place your storage choices live. It works on regular servers and on serverless platforms.

The hard parts

Not losing data when a server crashes

The obvious way to save totals is to read them, send them to the database, and delete them. If the server crashes partway through, those numbers are lost or stuck.

MetricHouse first moves the totals it’s about to save into a separate holding spot in Redis, which survives a crash. The next time any server saves, it checks for totals that have sat in holding too long, puts them back, and tries again. A crash delays the numbers but doesn’t lose them.

Saving the same numbers twice without counting them twice

Because a crash leads to a retry, the same totals can reach your database twice. Each saved row gets an id built from what it describes (which metric, which time window, which details), so a resend carries the same id and the database replaces the old row instead of adding a duplicate. When I measured where time went while saving large batches, building those ids was the slowest step, so I rewrote that code to be faster.

Exact live totals across many servers

Every server adds straight to the same shared totals in Redis instead of keeping its own count, so a live total is correct no matter how many servers you run.

Two storage options that behave the same

You can keep data in memory, for testing or a single server, or in Redis, for many servers. One shared set of tests checks that both behave the same way.

Results

• 1,664 npm downloads in its first three weeks (first release Sep 18, 2026). npm also counts automated installs, so this isn’t a count of people.
• I use it in the Adventure World ticketing platform to record where ticket buyers come from.
• Free and open source, with a documentation site.