FAQ

What is ServerDevTools?

An in-process Node.js request inspector. It shows request and response details, execution spans, database operations, outbound HTTP calls, errors, and timings in a local dashboard.

How does it differ from Postman and Swagger?

Postman  sends and tests API requests. Swagger documents an API contract. ServerDevTools observes what your running backend actually did after a request arrived.

How does it differ from hosted APM tools?

ServerDevTools is a developer-focused, in-process inspector with local SQLite storage. Hosted APM platforms such as Sentry  are designed for broader monitoring, centralized event collection, and team-wide visibility.

Which Node versions and frameworks are supported?

The SDK requires Node.js 20 or newer. Supported framework guides cover native Node HTTP, Express, and NestJS. Instrumentation also covers MongoDB, pg, mysql2, ioredis, native HTTP/HTTPS, and Undici fetch.

Does captured data leave my application environment?

The SDK has no ServerDevTools telemetry service or required collector. It writes to local SQLite. Outbound instrumentation observes your application’s own calls; it does not export them to ServerDevTools.

Can sensitive information be captured?

Yes. Request and response bodies, URLs/query parameters, selected headers, database/Redis data, errors, and user context can contain sensitive values. Header redaction is enabled for configured HTTP header values before persistence, and optional AES-256-GCM encryption protects configured fields at rest. Redaction is not complete body, URL/query, or arbitrary-span-attribute coverage. See security guidance.

Which HTTP headers are redacted?

By default, authorization, proxy-authorization, cookie, set-cookie, and x-api-key are matched case-insensitively. redaction.additionalHeaders extends that list; names are trimmed and de-duplicated. It applies to captured HTTP details and matching HTTP header span attributes. Existing records are not retroactively changed.

What happens when a captured body exceeds the limit?

Native outbound request and response body capture skips bodies above 256 KiB rather than storing partial data. Complete network payloads still reach the destination/application. Inbound response and fetch capture do not currently use that SDK byte limit, though streaming and non-text bodies may not be useful dashboard representations.

Where is data stored, and how do I delete it?

By default, SQLite is created at ./server-devtools.db relative to the process working directory. Use Clear History in the dashboard or delete an individual trace. Trace data has no automatic expiry or retention pruning.

Is it suitable for production?

It is intended for development and controlled environments. It adds instrumentation and persistence work, may capture sensitive application data, and has no published benchmark. If you use it outside development, secure the route, credentials, transport, storage, and capture settings yourself.

Why must instrumentation start before application imports?

OpenTelemetry patches supported libraries during startup. Preloading with --import or NODE_OPTIONS lets instrumentation register before application dependencies and database clients are imported; already-loaded modules cannot be instrumented retroactively. await devtools.start() waits for ServerDevTools’ startup contract; the currently installed OpenTelemetry NodeSDK.start() is synchronous, and ServerDevTools enables fetch capture before startup resolves. It does not wait for application requests, database connections, or an external telemetry service. Preloading adds startup work and a startup failure can prevent the application from starting.

How does it differ from the Server-Timing response header?

Server-Timing is an application-provided response header for exposing selected server metrics to supporting browser developer tools and Performance APIs; see the MDN reference . ServerDevTools persists supported request details and linked child spans in local SQLite for dashboard investigation, including database, Redis, outbound HTTP, and error details when capture conditions allow. They are complementary: ServerDevTools does not emit Server-Timing headers, and Server-Timing does not create a trace or persist request history. See the detailed comparison.

Does it require an OpenTelemetry Collector or separate dashboard server?

No. The SDK exports directly to local SQLite and serves /_devtools through the existing HTTP server.

Why are database operations missing?

Usually the driver loaded before preload, the operation ran outside an active request, or the driver is not one of the supported instrumentations.