Sentry Node.js SDK with ZipLogger: setup and support

Set up

In ZipLogger, open Settings → API keys and create a key with Can read data unchecked. Copy the Sentry DSN shown under it (shown once, like the key).
Install the SDK: npm install @sentry/node
Initialise it with that DSN. If you already use Sentry, only the DSN changes.

Set release to <service>@<git sha>. ZipLogger has no project per service: the part before @ is the service, and the SHA is the commit the regression engine blames from.

The DSN carries the key hex-encoded and always ends in /1. Point it at your workspace address (https://<workspace>.ziplogger.ai) or app.ziplogger.ai; both work.

const Sentry = require("@sentry/node")

Sentry.init({
  dsn: "https://[email protected]/1",
  release: `checkout-api@${process.env.GIT_SHA}`,   // service@commit
  environment: "production",
  tracesSampleRate: 0.2,
  enableLogs: true,   // Sentry.logger
})

What arrives

The test sample captured the same error twice inside a POST /checkout transaction with a database span and an HTTP span, sent a warning message, two structured logs and a cron check-in pair, then crashed with an unhandled error. Each answer was read back through ZipLogger’s own API.

Signal	With @sentry/node 11.8.0
Errors and Issues	Yes. `capture_exception` / `captureException` is an error line and an Issue; the same error twice is one Issue with two events, titled by the error type and culprit function.
Unhandled errors	Uncaught exceptions and unhandled rejections are reported by the SDK's global handlers (an uncaught exception arrives at level fatal, marked unhandled) and flushed before the process exits.
Stack frames, in_app, source lines	Yes. Frames carry in_app and five lines of source around each frame. Node's own internal frames are kept but folded as library frames.
Breadcrumbs, tags, user, contexts	Yes. Shown on the Issue page; tags are searchable as `tag.<name>`, the user as `userId`.
Release and environment	Yes. `release: "checkout-api@3f9a2c1"` gives the service `checkout-api` and the commit `3f9a2c1`; the release is listed under Releases.
Tracing	Yes. The transaction and its child spans become a trace (server root, client children), and the service appears in APM within a minute or two. Errors inside the transaction link to it.
Structured logs	Yes. Logger records become log lines at their level, grouped by their message template.
Cron check-ins	Yes. Each check-in is a log line; with a `monitor_config` the heartbeat is created and its schedule kept in step. A failed or missed run opens an incident.
Profiling	Partly. `@sentry/profiling-node` sends continuous profiles (`profile_chunk`): they appear as flame graphs per service and time range, but a chunk is not linked to a single trace yet.

Good to know

Version 11 streams spans as they finish (span items) instead of one transaction. ZipLogger rebuilds the trace from them: the root span, its children, their timing and attributes.
Before 2026-10-21 a field-name clash between a trace's root span and its children made the store refuse one or the other for the rest of the day. Fixed.
Not stored: replays recorded by the Sentry SDK, attachments, user feedback and client reports. The SDK gets a normal success answer for them. Past events stay in Sentry.

What carries over from Sentry, and what does not → · Sentry SDKs in the docs →