Developer tooling · 2026

dts-tracer

Policy-based request tracing for Express, in one line of middleware.

Role: Design, build and publish
When: 2026
Stack: TypeScript · Node.js · Express · npm
Links: npm Source

The problem

Why it needed to exist.

Full tracing stacks are heavy for small services, and most of what they collect is never read. dts-tracer flips it: decide what is interesting, capture only that, and let the app choose where it goes.

A small npm middleware that keeps only the requests worth looking at — the slow ones and the errors — and hands them to you through an in-memory log and a callback.

Constraints

Zero configuration to start.
Must not slow down the requests it watches.
Storage is the app’s decision, not the library’s.

The system

How dts-tracer decides what to keep

The middleware times each request while your handler runs untouched. When the response finishes, a policy checks duration and status; matching traces go to an in-memory buffer and an onTrace hook.

One line of middleware wraps every Express request.
Your handler runs untouched — the tracer only starts a clock.
When the response finishes, it records duration and status.
A policy decides what is worth keeping — slow requests, client errors, server errors — so logs stay small.
Matches land in an in-memory buffer you can expose, and an onTrace hook lets you persist them anywhere.

In use

What it looks like.

server.ts

import express from "express";
import { createTraceRequest, getTraceLogs } from "dts-tracer";

const app = express();

app.use(createTraceRequest());

app.get("/logs", (_req, res) => {
  res.json(getTraceLogs());
});

app.listen(3000);

From the READMEThe whole integration: one middleware, one endpoint to read the traces.

dts-tracer, in the open on GitHub. · captured Sep 2026 from github.com/bgantavya/distributed-tracing-system

Decisions

Three choices, and what each one cost.

01
Policy over sampling
Capturing by rule (slower than N ms, 4xx, 5xx) keeps every interesting request instead of a random slice.
Trade-offA burst of errors produces a burst of traces.
02
In-memory by default
getTraceLogs() works out of the box for a quick /logs endpoint during development.
Trade-offBounded and reset on restart — persistence is opt-in.
03
A hook, not an integration
onTrace(trace) sends traces to a database, a file or an observability tool without the library depending on any of them.
Trade-offYou write three lines of glue.

Outcomes

What changed.

line to adopt: 1; app.use(createTraceRequest())
published on npm, fully typed: v1.0
open source: MIT

What I’d do next

The next version.

OpenTelemetry-compatible export and per-route policies.

Something like this on your plate? Write to me.