Node API monitoring, from one npm install.
Every request your Node.js API serves, recorded with its payload, timing and queries, grouped by endpoint and watched for errors, slowdowns and breaking changes. Turn on host telemetry and you get the event loop, memory and CPU of every server running it too.
What is Node API monitoring?
Node API monitoring is recording the requests a Node.js API serves (which endpoint was called, by whom, with what payload, how long it took and what came back) and watching that traffic for errors, slow endpoints, breaking changes and abuse, alongside the health of the Node processes serving it.
Node API monitoring
The requests: which endpoints are slow, which are failing, who is calling them and what changed in the responses. This is what your customers feel.
Node monitoring
The process: CPU, memory, event-loop delay and garbage collection. This is why a request was slow when nothing in its own code explains it.
Six things to monitor in a Node.js API
Uptime checks say the API answered. These say whether it is working for the people calling it, and why not when it isn't.
Latency per endpoint
p50, p95 and p99 for each route, so GET /orders/{id} is one line on the chart. An average across the whole service hides the slow endpoint your biggest customer uses.
Errors with the request attached
Every 5xx kept with the payload that caused it, and client errors spread across many consumers flagged as your problem rather than one caller sending bad requests.
Queries and N+1s
Each database query, cache call and outbound request a route made, timed. N+1 patterns surface as "43 calls / request" instead of a vague slowdown.
Event loop and memory
Event-loop delay, heap, CPU and garbage collection from every Node process, so a slow request can be traced to the server that served it.
Breaking response changes
A field removed or retyped in a response breaks clients before any error rate moves. Drift detection compares each endpoint with its own history.
Regressions after a deploy
Release markers on every chart, and a list of which endpoints and queries got slower after each deploy, ranked by their impact on real traffic.
Monitor a Node.js API in three lines
One package, mounted where your framework expects middleware, before your routes. What runs is decided in your ApiTraffic account and pushed to every server, so turning a feature on is a dashboard change, not a deploy.
const express = require('express');
const apitraffic = require('@apitraffic/node');
const app = express();
app.use(express.json()); // parse first - verdicts read parsed bodies
app.use(apitraffic.express({
token: process.env.API_TRAFFIC_TOKEN,
bucket: process.env.API_TRAFFIC_BUCKET,
}));
app.get('/users/:id', (req, res) => {
res.json({ id: req.params.id });
});
app.listen(3000);express.json(), before your routes.Node 20+. Types included, no @types package. Read the middleware source →
One record per request, queries included
Each request is one record: the payload in and out, every query, cache call and outbound request it caused, and how long each took. Requests group by endpoint automatically, so percentiles and error rates line up per route without annotating anything.
- Search by endpoint, status, duration, header, tag or a field in the body
- Postgres, MySQL, MongoDB, Redis, fetch, axios and more, timed per request
- Incidents per endpoint, routed to Slack, email, PagerDuty, Jira or a webhook
The process behind the requests
Turn on host telemetry for a bucket and every Node.js server running the SDK reports its own CPU, memory, event-loop delay and garbage collection. The Servers page lists each process with its health, its share of the traffic and its restarts, lined up with the requests it served.
- Healthy, busy or degraded at a glance, from loop delay, heap and CPU
- See whether a slow period follows event-loop or memory pressure
- No agent to install, and no restart to turn it on or off
Monitoring that stays off your request path
A Node.js process has one event loop. Anything that monitors it has to leave that loop alone.
- Records in-process and returns immediately; payloads ship in batches off the event loop
- Fails open: if ApiTraffic is unreachable, your API carries on
- Credential headers and secret-looking keys masked before anything is sent
- Node 20+, TypeScript declarations included, no @types package
- An in-app firewall that reads the same requests it records
Node API monitoring questions
Node API monitoring is recording the requests a Node.js API serves (which endpoint was called, by whom, with what payload, how long it took and what came back) and watching that traffic for errors, slow endpoints, breaking changes and abuse, alongside the health of the Node processes serving it.
Install the ApiTraffic package for your framework (@apitraffic/node for Express, Fastify, Koa and Hapi; @apitraffic/nestjs for NestJS, @apitraffic/meteor for Meteor, @apitraffic/sails for Sails, @apitraffic/loopback for LoopBack, @apitraffic/strapi for Strapi and @apitraffic/adonisjs for AdonisJS) and register it before your routes, the way your framework expects: Express middleware, a Fastify plugin, a NestJS module and so on. Every request is then recorded and grouped by endpoint. For per-query timing, add @apitraffic/apm and start Node with it preloaded. For CPU, memory and event-loop delay, turn on host telemetry for the bucket.
Node monitoring usually means the health of the Node.js process: CPU, memory, event-loop delay and garbage collection. Node API monitoring is about the requests that process serves: endpoints, errors, latency and payloads. ApiTraffic does both from the same SDK, and lines them up so a slow period can be matched to the server and the requests behind it.
Yes. Turn on host telemetry for a bucket and each server running the SDK reports its CPU, memory, event-loop delay and garbage collection. The Servers page shows every process with its health and its share of the traffic, with no agent to install and no restart to change it.
Not with ApiTraffic. The SDK records each request in-process, returns immediately and ships payloads in batches off the event loop, so no network call to ApiTraffic happens between your handler and your response. If ApiTraffic is unreachable, your API keeps serving requests.
There are first-party SDKs for Express, Fastify, NestJS, Koa, Hapi, Meteor, Sails, LoopBack, Strapi and AdonisJS, with TypeScript declarations included. Current releases need Node.js 20 or later (the 1.x releases of @apitraffic/node still run on Node 18), and each framework guide lists the framework versions it supports.
Cloudflare decides whether a request gets in. We record what happened after it did.
Those are different jobs, and the gap between them is where most API incidents live. Your edge sees strangers - unknown IPs, bad signatures, known-bad patterns - and it’s good at that. What it can’t see is a legitimate, authenticated key behaving unlike itself: enumerating IDs one at a time, pulling fifty times its normal volume on a Sunday, or walking endpoints it has never touched before. That traffic passes every edge check, because it’s a customer.
Keep Cloudflare. We’re the layer inside your app where the caller has a name, a history, and a bill. The full comparison says what each one does better.
Datadog is a much broader product. If you need to monitor a Kafka cluster, build custom dashboards for forty services, and correlate across your whole estate, use Datadog - we’re not that, and we’re not trying to be.
We answer one question well: who called your API, and what happened. Because logging, timing, and screening run in one middleware, you get one record per request with the trace and the security verdict already on it. Nothing to correlate by request ID across three products and three clocks at 2am.
The other difference is structural. There’s no host agent to deploy, so there’s no per-host meter and no bill that grows every time you add a container.
What we don’t do: infrastructure monitoring, RUM, log ingestion from things that aren’t your API, or 800 integrations. The full comparison covers pricing and running both.
No. The middleware fails open.
If our collector is unreachable, requests complete exactly as they would without us. Telemetry queues into a bounded in-memory buffer and is dropped once that buffer is full - it never grows without limit, and it never blocks a response. You lose visibility for the duration of the outage. You don’t lose traffic.
Enforcement is a separate question, and the answer is better than fail-open usually implies. Verdicts are evaluated in your process against the policy you last synced, not by calling us - so a rule that was live when the connection dropped is still live now. During an outage you stop receiving policy changes; you do not stop being protected. The kill switch works the same way: API_TRAFFIC_WAF_ENABLED=false takes effect without a deploy and without reaching us, which is the case that matters when we are the problem.
Yes, through the proxy URL - and the SDKs are Node because that is where we can go deepest.
For any other stack, generate a proxy URL for your bucket: the same URL as your API call with only the hostname changed. Calls sent through it land in your request log, searchable, grouped by endpoint and watched by alerting, from any language and with no code to install.
The SDKs add what only an in-process middleware can see: your route definitions (/users/:id as one endpoint instead of forty thousand paths), the outbound calls your app makes, the queries behind each request, and a firewall that inspects the parsed request. That is why the first-party SDKs are for Node frameworks.
You decide what is kept, and the secrets are masked before you configure anything.
From the very first request, credential headers - Authorization, cookies, API key and CSRF headers - and secret-looking keys in bodies and query strings are masked inside your process, before anything is sent.
On top of that, redaction rules mask your own fields, either in your app so the value never leaves your server or on our side just before storage. Exclusion rules keep a route out entirely, or log its requests without their bodies. Everything you see afterwards - the request log, share links, embeds, the API and the MCP server - sees only the redacted value.
Keep them. Application logs are what your code chose to say. We record what actually crossed the wire.
The difference shows up on the requests you didn’t write a log line for: the ones that 404’d before reaching a handler, the ones that failed auth, the ones hitting a route someone shipped last quarter and forgot. Those don’t appear in your app logs precisely because your code never ran - and they’re disproportionately the ones worth looking at.
There’s also no correlation step. The timing and the verdict are already on the record; you’re not grepping a log drain and joining it to something else by hand.
The middleware is public on GitHub if you’d rather read it than take our word for what it does on the request path.
ApiTraffic tells you - alerts are on every plan.
Every endpoint is compared with its own normal, and a change has to be a multiple of normal, big in real terms and statistically real before anyone is told. Related alerts become one incident, sent to Slack, email, PagerDuty, Jira or a webhook following your routing. Each alert says why it was grouped, traffic alerts link straight to the requests behind them, and an alert that needs its own owner can be split into an incident of its own. Drift detection adds breaking API changes, certificate monitoring warns you before the certificate of a host your API calls expires, and deploy markers let you see which release changed what. How alerting works
Know what your API did - before your customers tell you.
One npm install and one line of code. Your first requests arrive in minutes, with their queries, their firewall verdict and a baseline for every endpoint already building.
Free trial · No credit card · Set up in minutes