Monitoring Express, Fastify, and NestJS APIs

Your Node framework routes requests brilliantly and tells you nothing about how they perform in production. Express, Fastify, and NestJS all leave observability as an exercise for the reader. The reader, at 3am, is you.

How Do Express, Fastify, and NestJS Compare?

Express still runs an enormous share of production Node. Fastify wins on raw throughput. NestJS brings structure to larger codebases. What none of them ship is a per-route view of P95 latency and error rate.

Express: One Middleware Line

import { Statvisor } from "@statvisor/sdk";

const sv = new Statvisor({ apiKey: process.env.STATVISOR_API_KEY! });

app.use(sv.express());

Fastify: Register the Plugin

import { Statvisor } from "@statvisor/sdk";

const sv = new Statvisor({ apiKey: process.env.STATVISOR_API_KEY! });

await fastify.register(sv.fastify());

NestJS: Reuse the Express Adapter

NestJS runs on Express by default, so the Express adapter drops straight into your bootstrap. Grab the underlying instance and hand it the middleware:

import { Statvisor } from "@statvisor/sdk";

const sv = new Statvisor({ apiKey: process.env.STATVISOR_API_KEY! });

const app = await NestFactory.create(AppModule);
app.use(sv.express());

What Do You Get After One Line of Setup?

Once the adapter is in, every route reports P50, P95, and P99 plus its error rate, without decorators or manual timers. When we benchmarked the Fastify plugin, the added latency stayed within measurement noise. The slow endpoint stops hiding behind a healthy average. If your slow route is database-bound, the Supabase and Prisma latency guide covers the next step.

Read the Output Like a Pro

Numbers only help if you read the tail. Alert on P95, dig into P99, and check them per route. Start with P50 vs P95 vs P99: why averages lie, and if you build on Next.js, the same one-line idea covers App Router in Next.js observability.