I got tired of console.log debugging, so I built DevTools for my backend

You know the dance.

An endpoint is slow. So you open the handler and start sprinkling:

console.log("got here");
console.log("query done", Date.now() - t0);
console.log("still here??");

Enter fullscreen mode Exit fullscreen mode

Then you squint at tail -f, mentally stitch the lines back into an order,
and try to remember which log came from which request, because three of them
are interleaved.

I did this for years. Then one day it hit me that the frontend solved this
fifteen years ago. You open DevTools, you get a Network tab, and you just
see it. Waterfall, timings, what fired when.

The backend never got that. So I built it.

Wevna

One line, at the top of whatever file boots your server:

// server.js / index.ts / main.ts, as early as you can
import { wevna } from "@wevna/sdk";

await wevna.start();

// ...your Express / Fastify / Nest app, completely unchanged

Enter fullscreen mode Exit fullscreen mode

Open localhost:4123. Hit an endpoint. That’s the entire setup: no
middleware to register, no context object to pass around, nothing else to
touch.

Every HTTP request, SQL query, Redis command, console.log and uncaught
exception, grouped under the request that caused it, automatically. No
context object to thread through your handlers. No config file. No agent.

The bit that made it worth finishing

I pointed it at a demo app with a deliberately dumb loop in it, and it said
this without being asked:

Repeated Query
The same query ran 4 times, taking 198ms in total:
select * from "orderitems" where "orderid" = ?

Enter fullscreen mode Exit fullscreen mode

That’s an N+1. It found it by noticing four queries with the same shape but
different values, which is what an N+1 actually looks like from the outside.

It won’t tell you it’s a bug, because sometimes it isn’t. It just puts the
number in front of you.

The part I care about most

Nothing leaves your machine.

No account. No API key. No egress. The dashboard binds to localhost, the
data lives in memory in your own process, and I have no idea you’re running
it. It’s a devDependency in spirit, closer to DevTools than to Datadog.

It’s also deliberately careful about what it captures:

• SQL parameter values are never read, only the query text
• Redis command arguments are never recorded: commands like SET session:abc <token> carry secrets inline, so there’s no safe subset
• console.log is stored as the formatted string, never the raw objects

What it can’t do (yet)

Full honesty, since this is v1:

• Postgres and Redis only. MySQL and Mongo aren’t there.
• Memory-bounded. Built for a debugging session, not to run for a week.
• The dashboard is unauthenticated. It’s on localhost for that reason.
• It reports rather than diagnoses. It’ll show you a repeated query; it won’t claim to know why.

Where I’d like it to go

The thing I actually want is a time machine for backend bugs.

Recording and replay already work: you can dump a session to a JSON Lines
file and scrub through it later, at 0.25× to 8×, with no app running. Every
part of the UI works at whatever position you’ve scrubbed to.

So the shape of it is already there:

Prod does something weird at 3am. A recording lands in your repo. You open
it on your laptop next morning and watch it happen, step by step, like a
replay.

That’s the version I’m building toward. Attaching a recording to a bug report
instead of pasting log fragments into Slack.

Try it

There’s a runnable demo (no database or containers needed):

git clone https://github.com/wevna/wevna.git
cd wevna && pnpm install && pnpm build
pnpm --filter @wevna/example-express dev

Enter fullscreen mode Exit fullscreen mode

Then curl localhost:3000/orders/42 and watch the dashboard. That endpoint
has the N+1 in it.

Or drop it into your own app:

npm install @wevna/sdk

Enter fullscreen mode Exit fullscreen mode

GitHub: https://github.com/wevna/wevna
npm: https://www.npmjs.com/package/@wevna/sdk

MIT. Node 22+. Built over the last few months, ~900 tests, and genuinely used
by me to debug my own stuff.

I’d really like to know two things:

1. Does it survive contact with your app? It’s been tested by exactly one person so far, and that person is biased.
2. What’s the first thing you went looking for and couldn’t find?

Issues, replies, whatever’s easiest. I’m listening.