Observability Best Practices
Alert on symptoms, not every stack trace. These rules keep Node.js observability actionable, affordable, and correlated across logs, metrics, and traces.
//
Search across all documentation pages
Alert on symptoms, not every stack trace. These rules keep Node.js observability actionable, affordable, and correlated across logs, metrics, and traces.
/users/:id). Never UUIDs in metric dimensions.instrumentation.ts before framework imports. HTTP auto-instrumentation requirement.traceparent on outbound HTTP. Downstream services continue trace.trace_id into Pino logs via mixin or ALS. Log-trace correlation in APM.requestId alongside trace_id during migration. Support and legacy tools.sdk.shutdown() on SIGTERM. Flush spans before pod kill.OTEL_SERVICE_NAME per deployment. Service catalog accuracy.Pino JSON logs with requestId + RED metrics + 10% trace sampling on staging before prod.
Logs first (cheap, always on). Metrics second (SLOs). Traces third (debugging depth).
Platform/SRE team typically. App teams own instrumentation.ts and service.name.
Check instrumentation load order and whether route bypasses instrumented HTTP stack.
HTTP-level RED plus optional per-operation spans with bounded operation name cardinality.
Separate service.name. Same OTel bootstrap pattern; trace job execution as root span.
Treat traces/logs as sensitive data stores - RBAC, retention TTL, no secrets in attributes.
Logging Best Practices covers log specifics; this list covers full observability stack.
Stack versions: This page was written for Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5, and NestJS 11.
Reviewed by Chris St. John·Last updated Jul 16, 2026