Now capturing silent 5xx responses
Zero-overhead Node.js
error tracking and telemetry
Capture unhandled exceptions, request context and HTTP bottlenecks from your Node.js services straight into ClickHouse. Events are buffered and flushed off the request path, grouped by root cause, and ingested without monthly quotas.
- Unmetered ingestion — no event caps
- ClickHouse-backed querying
- PII redaction on by default
Read the technical fact sheet or compare against Sentry and Datadog.
import { VantaTrace } from '@vantatrace/sdk';
const vantaTrace = new VantaTrace({
apiKey: process.env.VANTATRACE_API_KEY,
});
app.use(vantaTrace.requestHandler());
// uncaught exceptions, rejections, and
// silent 5xxs — captured automatically.npm install @vantatrace/sdk
Built for the stack you already run
Built for your architecture.
From massive monoliths to ephemeral serverless functions, VantaTrace adapts to how you ship code.
Trace a single request as it hops across 10 different services.
Stop guessing which service dropped the ball. VantaTrace automatically propagates trace headers across HTTP boundaries, stitching together a unified root-cause analysis for distributed architectures.
- Automatic Trace ID propagation
- Cross-service stack trace stitching
- Identifies the exact failing downstream node
// auth-service.js
const { captureException, getActiveTraceId } = require('@vantatrace/sdk');
app.post('/verify', async (req, res) => {
try {
await verifyToken(req.body.token);
} catch (err) {
captureException(err, {
metadata: { service: 'auth-service' }
});
// The exact Trace ID is passed to checkout-service
res.status(401).json({ error: 'Invalid Token', traceId: getActiveTraceId() });
}
});One console for everything that can go wrong
Most teams stitch together a logger, an APM, and a spreadsheet of incident notes. VantaTrace replaces the stitching with one pipeline from request to root cause.
Errors
Uncaught exceptions, unhandled rejections, and silently swallowed try/catch failures — captured with full stack, request context, and a synthetic trace when the source is hidden.
Performance
Per-route latency, throughput, and slow-endpoint detection — so a regression shows up in the console before it shows up in a support ticket.
Tracing
Follow a single request as it crosses services. Correlation IDs tie the gateway hop to the worker hop to the database call it eventually blamed.
Logs
The events leading up to a failure, not just the failure itself — console, Winston, and Pino output normalized into one readable timeline.
Metrics
Redis-backed counters update on ingest, so quota, error-rate, and volume widgets reflect what happened seconds ago — not last night’s batch job.
Analytics
Every occurrence lands in a columnar store built for scans, not lookups — filter by MSISDN, user, project, or environment without a slow query in sight.
A console that reads like your incident channel, not a spreadsheet
Switch between issues, performance, and traces without leaving the page — everything shares the same time range, the same filters, the same request.
Issue explorer
Grouped by fingerprint, sorted by impact, filterable by environment, service, or MSISDN.
Performance graphs
p50/p95/p99 latency and throughput, per route, updated in real time.
Request waterfall
A span-level breakdown of where a slow request actually spent its time.
Two lines in, five minutes to your first issue
The same middleware wires into whatever's already serving your Node.js requests.
import express from 'express';
import { VantaTrace } from '@vantatrace/sdk';
const app = express();
const vantaTrace = new VantaTrace({ apiKey: process.env.VANTATRACE_API_KEY });
app.use(vantaTrace.requestHandler());
// ...your routes...
app.use(vantaTrace.errorHandler());
app.listen(3000);An ingestion path designed for traffic you haven't hit yet
A telemetry agent that slows down the thing it's watching defeats the point. VantaTrace dispatches asynchronously, queues through Redis and BullMQ, and writes into ClickHouse — so a traffic spike in your app becomes a queue depth, not an incident in your API.
Async by default
Capture is queued via BullMQ and shipped off the request thread. Nothing you instrument ever adds latency to a response.
Redis-backed counters
Quota and rate metrics update on ingest, not on a nightly rollup — the dashboard reflects what happened seconds ago.
ClickHouse storage
Occurrences land in a columnar store built to scan millions of rows per query — filter by project, user, or MSISDN without a slow query in sight.
Stateless workers
Ingestion workers hold no local state. Scale out horizontally when volume grows; nothing to re-architect.
How an exception becomes an issue
Five steps, none of them blocking the request that triggered them.
SDK
Middleware captures the exception, context, and request metadata in-process.
Queue
Payload is pushed onto a BullMQ job and the request thread moves on immediately.
Worker
A stateless worker normalizes, redacts, and groups the event by fingerprint.
ClickHouse
The occurrence is written to a columnar store built for fast, wide scans.
Dashboard
Issue, trend, and project views query ClickHouse and update live.
Everything an on-call engineer actually reaches for
Error Monitoring
Every unhandled error, captured with full context.
Exception Tracking
Swallowed try/catch failures recovered at the throw site.
Performance Monitoring
Per-route latency and slow-endpoint detection.
Distributed Tracing
Follow a request as it crosses services.
Request Analytics
Filter by project, user, environment, or MSISDN.
API Monitoring
Status codes, response bodies, and route health.
ClickHouse Analytics
A columnar store built for scans, not lookups.
Session Insights
User, tenant, and session context on every occurrence.
Smart Issue Grouping
Fingerprinted by name, message, and stack location.
Real-time Dashboards
Redis-backed counters update the moment events land.
Alerts
In-app, live socket, and Slack alerts on new issues.
SDKs
One middleware for Node.js, Express, and NestJS.
Multi-language Support
Console localizes to your team, not just your stack.
Frequently asked questions
Direct answers about architecture, overhead, data handling and cost.
What is VantaTrace?
VantaTrace is an open developer observability platform for Node.js that captures unhandled exceptions, request context and distributed traces, and stores them in a ClickHouse columnar database. The SDK batches events in memory and flushes them asynchronously over HTTPS, so capturing an error does not block the request that produced it. It installs with a single npm package, @vantatrace/sdk, and ingestion is free and unmetered.
Is VantaTrace free to use?
Yes. VantaTrace telemetry ingestion is free and unmetered: there is no monthly event cap, no per-event overage billing and no separate ceiling on development or test projects. Events are never discarded for exceeding a plan allowance. Per-IP, per-API-key and per-project rate limits still apply, but these exist to absorb floods and abuse rather than to meter usage.
How does VantaTrace avoid adding Node.js event loop lag?
VantaTrace keeps exception capture off the request path by buffering events in memory and flushing them on a timer rather than sending one HTTP request per error. Batches are gzipped above 10 KB and sent over pooled keep-alive connections, and the ingest endpoint answers HTTP 202 as soon as the batch is queued, so the SDK never waits on storage. Persistence happens afterwards in a BullMQ worker, outside the application process entirely.
How does VantaTrace compare to Sentry and Datadog?
VantaTrace differs from Sentry and Datadog in two ways that matter operationally: event storage is a ClickHouse columnar database rather than a row-oriented store, and ingestion is unmetered rather than billed per event. Columnar storage is what makes aggregate queries across millions of exceptions cheap, because a query that groups by release or route reads only those columns. The practical consequence is that a traffic spike produces a larger bill of exactly zero, instead of an overage or dropped events.
Does VantaTrace redact passwords and personal data?
Yes. VantaTrace recursively scrubs request bodies, query strings, headers, cookies and error message text before events are stored, and it is on by default rather than opt-in. The scrub runs twice: once in the SDK before transmission, and again independently in the ingestion worker. That second pass is the one that matters for guarantees, because an outdated SDK version or a request posted directly to the authenticated ingest endpoint bypasses client-side scrubbing entirely.
Which frameworks and runtimes does VantaTrace support?
VantaTrace supports Node.js 18 and later, with first-class integrations for Express, Fastify and NestJS, and it works with Next.js in both the App Router and the Pages Router. The SDK attaches via middleware or a framework plugin and uses AsyncLocalStorage to associate a captured exception with the request that caused it. A single call to captureException also works anywhere, with no framework integration at all.
How does VantaTrace group duplicate errors?
VantaTrace groups duplicate errors by fingerprinting the exception name, message and top stack frames into an MD5 hash, then collapsing every matching occurrence into one issue. The fingerprint is computed before PII scrubbing, so redacting a value cannot split one real issue into several groups. Each group keeps its own first-seen and last-seen timestamps and an occurrence count, so a recurring error stays a single entry in the dashboard rather than thousands.
What stops a crash loop from flooding VantaTrace?
VantaTrace rate-limits on both sides of the connection. The SDK caps itself at 1,000 events per minute overall and 150 per minute for any single error fingerprint, which stops a tight recursive crash loop from exhausting the host process or saturating its network. The backend separately enforces 1,000 requests per minute per IP, 5,000 per API key and 10,000 per project over sliding 60-second windows, with repeated violations triggering a temporary automatic suspension of the offending key.
Looking for exact specifications? Read the technical fact sheet.