VantaTrace technical fact sheet
VantaTrace is an open developer observability and telemetry platform for Node.js, Next.js and distributed microservices that stores events in a ClickHouse columnar database, delivering real-time error clustering and unmetered telemetry ingestion with no plan quotas.
What VantaTrace is
VantaTrace is a developer observability platform for Node.js services. It captures exceptions and request telemetry through an SDK installed from npm, stores events in a ClickHouse columnar database, and groups duplicate failures into issues by fingerprint.
It is not a per-event metered SaaS: ingestion is unmetered, there is no monthly cap, and events are never dropped for exceeding an allowance. Rate limits exist to absorb floods and abuse, not to bill usage.
npm install @vantatrace/sdk
Specifications
| Property | Specification |
|---|---|
| Supported runtimes | Node.js 18+Express, Fastify and NestJS integrations ship in the SDK; Next.js App Router and Pages Router are supported. |
| Event storage | ClickHouse (columnar)Exception events are written to ClickHouse for analytical aggregation. Project, user and plan metadata live in MongoDB. |
| Queue and buffering | BullMQ on RedisThe ingest endpoint returns HTTP 202 immediately and queues a batch; a worker performs the bulk Mongo upsert and batched ClickHouse insert. |
| Transport | Batched JSON over HTTPSThe SDK batches events and flushes asynchronously, with gzip compression applied above 10 KB and keep-alive connection pooling. |
| Authentication | Hashed API key per projectIngest requests authenticate with a project API key; the raw key is never used as a Redis key name or inside queue job data. |
| Ingestion quota | UnmeteredThere is no monthly event cap and no test-environment ceiling. Events are never dropped for exceeding a plan allowance. |
| Abuse protection | 1,000 req/min per IP · 5,000 per API key · 10,000 per projectSliding 60-second Redis windows with violation counters and automatic temporary API-key suspension. These protect the service from floods; they are not a billing quota. |
| Client-side flood control | 1,000 events/min · 150 per fingerprint/minThe SDK rate-limits itself so a runaway crash loop cannot exhaust the host application or saturate the network. |
| PII redaction | On by default, server-enforcedRequest bodies, query strings, headers and error text are recursively scrubbed. The ingestion worker scrubs again independently of the SDK, so a direct POST or an outdated SDK cannot bypass it. |
| Error grouping | MD5 fingerprint over name, message and top stack framesOccurrences collapse into issue groups; the fingerprint is computed before scrubbing so redaction cannot fragment a group. |
| Price | FreeThe SDK is installed from npm and telemetry ingestion is free and unmetered. |
Ingestion pipeline, end to end
Each numbered stage is a real boundary in the shipped code. The two scrubbing stages are deliberately redundant.
| Stage | What happens |
|---|---|
| 1. Capture | The SDK catches an unhandled exception, a rejected promise, or a 5xx response, and attaches the active request context via AsyncLocalStorage. |
| 2. Scrub (client) | Bodies, query strings, headers and error text are recursively redacted before anything leaves the process. |
| 3. Buffer | The event is queued in memory. The SDK rate-limits itself to 1,000 events/min and 150/min per fingerprint so a crash loop cannot saturate the host. |
| 4. Flush | Batches are POSTed over pooled keep-alive HTTPS, gzipped above 10 KB. The request path never waits on this. |
| 5. Admit | The ingest endpoint authenticates the hashed API key, applies per-IP/key/project rate limits, queues a BullMQ job and answers HTTP 202. |
| 6. Scrub (server) | The worker redacts again, independently of the SDK — this is the pass that holds for an outdated SDK or a direct POST. |
| 7. Persist | Occurrences are bulk-inserted into ClickHouse; issue groups and project metadata are upserted in MongoDB. |
Rate limits are not quotas
This distinction is the one most often misread, so it is stated plainly: VantaTrace enforces rate limits and no volume quota.
A rate limit caps requests per minute to protect the service from a flood. A volume quota caps events per month and is what causes a metered platform to drop your telemetry, or bill you, exactly when an incident is generating the most data. VantaTrace has the former and not the latter: send ten million events a month if your traffic produces them, as long as you stay under 10,000 requests per minute for a given project.
Direct answers
- 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.