Backend errors on Node

Backend errors authenticate with the Project secret key, so they arrive Internal tier and tagged platform: node. Fleet-wide crash-loops collapse into a single Issue with a rising occurrence count instead of flooding your queue.

Install

npm install @fixback/node

The Express and NestJS adapters are optional — install the framework you use.

Quick start

Call init as early as possible in your process — before your app boots — so the process handlers are installed before anything can throw:

// instrument.ts — imported first in your entry fileimport { init } from "@fixback/node";init({  secretKey: process.env.FIXBACK_SECRET_KEY!, // sk_… (never your publishable key)  environment: process.env.NODE_ENV,          // "production" | "staging" | …  release: process.env.GIT_SHA,               // symbolicated against your uploaded sourcemaps  enabled: process.env.NODE_ENV === "production", // gate auto-capture off in local dev});

That single call wires:

• a batched secret-key transport that backs off on 429 (honouring Retry-After);
• process-level uncaughtException / unhandledRejection capture that never changes your process's exit behaviour;
• and the manual capture API below.

Manual capture

Report a handled error or a message from anywhere in your process:

import { captureException, captureMessage } from "@fixback/node";try {  await risky();} catch (err) {  captureException(err);           // handled: true}captureMessage("cache miss storm", "warning");

Confirming the connection

The browser and Expo SDKs announce themselves the moment they load, so a Project with either installed flips to Connected on the next page view. A server has no equivalent moment — @fixback/node sends nothing until it captures something — so the first capture is what confirms the install. Trigger one deliberately:

import { captureException } from "@fixback/node";captureException(new Error("Fixback test"));

The Project's status flips as soon as that batch lands, and the error arrives in the queue as an Internal-tier Issue you can resolve straight away. If nothing shows up, check that enabled is not gating capture off in this environment and that the secret key has not been revoked.

Express

import express from "express";import { fixbackRequestContext, fixbackErrorHandler } from "@fixback/node/express";const app = express();app.use(fixbackRequestContext()); // opens per-request context (before your routes)// … your routes …app.use(fixbackErrorHandler());   // captures errors that reach next(err) (after your routes)

NestJS

import { Module } from "@nestjs/common";import { FixbackModule } from "@fixback/node/nestjs";@Module({ imports: [FixbackModule.forRoot()] })export class AppModule {}

FixbackModule.forRoot() registers the request-context middleware and a global exception filter that captures thrown request errors and re-throws them, so your own error handling is unchanged.

Attaching a user

The SDK never scrapes user identity. Attach an app-supplied reference from inside a request and it rides along with any error captured during that request:

import { setUser } from "@fixback/node";setUser(currentUser.id); // an opaque ref you choose — not a name/email unless you send one

Privacy & fail-quiet

Private by default: the SDK captures the route pattern (never the concrete path with values), method, status, a correlation id, and the app-supplied user ref only — never bodies, auth/cookie headers, env vars, or query values. A beforeSend(event) hook redacts further or drops an event (return null). See Privacy & data.

And it fails quiet: if Fixback is unreachable or misconfigured, your server keeps running normally — observability never becomes an outage.