How to Enable Performance Tracing in Sentry for Node.js

Error monitoring tells you that a request failed. Performance tracing helps explain where time was spent during a request and how work is related across spans.

Modern Sentry Node.js tracing no longer uses the old @sentry/tracing package or the old startTransaction() / span.startChild() API pattern found in many historical tutorials. The current stable Node SDK supports tracing directly, and the modern manual API uses helpers such as Sentry.startSpan().

This tutorial is pinned to the current stable SDK at the time of writing and intentionally avoids the Sentry 11 beta APIs as production defaults.

Last verified: September 10, 2026. npm lists @sentry/node 10.74.0 as latest and 11.0.0-beta.2 as next. Revalidate version-specific APIs before publication or implementation after this date.

What You'll Accomplish

You will:

1. verify the current stable Sentry Node SDK;
2. enable trace sampling;
3. load tracing instrumentation before application modules;
4. generate an automatically instrumented server request;
5. add a manual custom span with the current startSpan() API;
6. verify trace/span data in Sentry; and
7. troubleshoot sampling, initialization, and OpenTelemetry conflicts.

Prerequisites

You need:

• a Sentry Node.js project;
• @sentry/node installed and error monitoring already verified;
• a supported Node.js runtime;
• a simple HTTP/Express-style application;
• permission to generate safe test traffic;
• understanding of the cost/volume implications of trace sampling in your Sentry plan.

Do not enable 100% production sampling simply because a tutorial uses it briefly for deterministic verification.

Quick Answer

Initialize the current stable @sentry/node SDK before importing the application and add a trace sampling setting such as tracesSampleRate: 1.0 only in a controlled development/staging verification environment. Start the app using the same early instrumentation approach as error monitoring. Generate a few requests and confirm that Sentry receives server transactions/spans. For custom work, use the modern API Sentry.startSpan({ name: "..." }, callback) rather than old startTransaction() or @sentry/tracing examples. After verification, reduce or replace the development sampling configuration with a production sampling strategy based on traffic volume and diagnostic needs.

Step 1: Verify the SDK Version and Ignore Legacy Tutorials

At verification time:

@sentry/node stable: 10.74.0
Sentry 11: beta / next tag

Install the stable SDK:

npm install @sentry/node

or pin this article's verified release for a reproducible lab:

npm install @sentry/[email protected]

Do not install @sentry/tracing

Historical Sentry tutorials often contain:

npm install @sentry/tracing

or:

require("@sentry/tracing");

Do not use that pattern in a current Node.js setup.

Sentry's migration documentation records the removal of the standalone @sentry/tracing package from the modern SDK line.

Do not use old transaction APIs

Historical examples may also use:

Sentry.startTransaction(...)

and:

span.startChild(...)

Sentry's modern performance API replaced those patterns with:

• Sentry.startSpan();
• Sentry.startSpanManual(); and
• Sentry.startInactiveSpan().

This tutorial uses startSpan() for a bounded callback.

Step 2: Enable Trace Sampling in the Instrumentation File

Starting from the error-monitoring setup, update instrument.mjs:

import * as Sentry from "@sentry/node";

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV || "development",
  tracesSampleRate: 1.0,
});

For CommonJS:

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

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV || "development",
  tracesSampleRate: 1.0,
});

Why 1.0 only for verification?

A sample rate of 1.0 attempts to keep every eligible trace. That is convenient when you are generating only a few deliberate test requests because it removes "was the test sampled?" ambiguity.

It is not a universal production recommendation.

Production sampling should consider:

• request volume;
• cost/retention limits;
• critical services;
• error/latency investigation needs;
• head-based sampling tradeoffs; and
• any dynamic sampling capability currently supported by the SDK/platform.

After verification, choose a deliberate production rate or current sampling callback strategy rather than leaving 1.0 by habit.

Step 3: Load Sentry Before Express and Other Instrumented Modules

Initialization order remains important for tracing.

With ESM:

node --import ./instrument.mjs app.mjs

With CommonJS, require the instrumentation file before Express:

require("./instrument");

const express = require("express");

If the SDK loads after Express or database/network modules, automatic spans can be missing even though Sentry itself appears initialized.

This is one of the highest-value troubleshooting checks for server-side tracing.

Step 4: Generate an Automatically Instrumented Request

Create a small route:

import express from "express";

const app = express();

app.get("/trace-test", async (req, res) => {
  await new Promise((resolve) => setTimeout(resolve, 100));
  res.json({ ok: true });
});

app.listen(3000, () => {
  console.log("Listening on http://localhost:3000");
});

Start the application with Sentry preloaded, then request:

curl http://localhost:3000/trace-test

Repeat it a few times in your test environment.

The exact automatically generated span structure depends on the SDK, framework, Node version, and integrations in use. Do not promise one exact tree.

The verification goal is simpler:

• a server request appears as trace/performance data;
• its duration is plausible; and
• the relevant route/service is identifiable.

Step 5: Add a Manual Span for Important Custom Work

Automatic instrumentation cannot understand every business operation.

If part of a request does custom work you want to measure, use the modern startSpan() API.

For example:

import * as Sentry from "@sentry/node";

async function loadReport() {
  return Sentry.startSpan(
    {
      name: "load-report",
      op: "app.report",
    },
    async (span) => {
      span.setAttribute("report.type", "summary");

      const report = await buildReport();

      return report;
    }
  );
}

The callback's work is measured by the span.

Avoid sensitive span attributes

Do not add:

• access tokens;
• raw authorization headers;
• passwords;
• payment data;
• full request bodies;
• sensitive customer identifiers.

Attributes should help explain performance without becoming a second copy of confidential application data.

Use manual spans sparingly

Manual tracing is most valuable around work the automatic integrations cannot identify clearly, such as:

• domain-specific processing;
• expensive transformations;
• custom queues;
• third-party SDK calls without instrumentation; or
• internal operations that matter to latency.

If every function becomes a span, traces become noisy and more expensive to process.

Step 6: Verify the Trace in Sentry

Generate the request again and open Sentry's performance/trace view for the project.

Confirm:

• a recent trace exists;
• the server request is present;
• duration is plausible;
• the custom load-report span appears when that code path executes;
• span parent/child relationships make sense; and
• the event/trace belongs to the intended environment.

If error monitoring works but no traces appear, sampling and initialization order are the first two things to check.

Step 7: Tune Sampling for Production

After deterministic verification, remove the assumption that every trace should be retained.

For example, replace:

tracesSampleRate: 1.0

with a lower rate chosen for your workload:

tracesSampleRate: 0.1

The value 0.1 here means "sample approximately 10%" in the basic head-sampling model. It is an example, not a recommended production default.

A low-traffic critical API and a high-throughput event ingestion service may need very different strategies.

Before implementing advanced/dynamic sampling, consult the current stable Sentry SDK documentation. Do not copy an old callback signature from a previous major release.

Step 8: Understand Sentry and OpenTelemetry Interoperability

This area is actively changing and is one reason the article is version-pinned.

The current stable v10 package includes OpenTelemetry-related dependencies/integration behavior internally.

The Sentry v11 migration material says v11 changes server-side behavior so Sentry no longer sets up an OpenTelemetry tracer provider by default for most server SDKs, producing native Sentry spans instead. However, v11 is still beta at this article's verification date.

Therefore:

• do not write v11 behavior as if it already applies to stable v10;
• do not manually add @sentry/opentelemetry just because you use @sentry/node;
• use the extra package only when you intentionally need to connect a custom OpenTelemetry setup as current Sentry documentation requires; and
• recheck interoperability when upgrading major versions.

If your application already owns an OpenTelemetry SDK/Collector pipeline, plan the integration rather than letting two libraries both try to control tracing context/export.

Step 9: Correlate Errors and Traces

One of the useful outcomes of tracing is context around a slow or failing request.

Generate a controlled error inside a traced test request and confirm that the error is associated with the expected request/trace context where the SDK supports it.

Do this in staging or a dedicated test route.

Do not intentionally throw errors into a production checkout or customer flow just to validate trace correlation.

The desired operational outcome is:

error event → affected request → surrounding spans → likely slow/failing dependency

not simply "we have more telemetry."

Verify the Setup

Tracing is ready when:

• the intended stable @sentry/node version is installed;
• Sentry initializes before instrumented modules;
• trace sampling is enabled for the test environment;
• a generated HTTP request appears in Sentry;
• a current Sentry.startSpan() custom span appears when executed;
• the trace has the correct environment/service context;
• no legacy @sentry/tracing dependency is required;
• production sampling has been deliberately chosen; and
• sensitive information is not being attached to spans.

Remove or protect any temporary verification route after testing.

Common Problems and Fixes

Problem: Errors appear, but no performance traces appear

Possible causes:

• tracesSampleRate or the current sampling mechanism is not enabled;
• the rate is so low that your small test was not sampled;
• Sentry initialized too late;
• the request is outside supported automatic instrumentation; or
• version-specific configuration differs.

Fix: in a controlled test environment, temporarily use deterministic high sampling, verify early initialization, and generate several requests. Return to a production-appropriate sampling strategy afterward.

Problem: Express requests appear, but a custom operation is invisible

Cause: automatic instrumentation covers the framework request but not your business function.

Fix: wrap only the important operation in the current Sentry.startSpan() API and verify the resulting span.

Problem: Old code using startTransaction() no longer works

Cause: the code follows a pre-v8 performance API.

Fix: migrate to the current span APIs. Do not reinstall @sentry/tracing to keep an obsolete tutorial alive.

Problem: Traces are disconnected or duplicated with OpenTelemetry

Cause: Sentry and a separately configured OpenTelemetry SDK may both be involved in context/provider/export setup.

Fix: stop adding integrations blindly. Document which system owns the OpenTelemetry provider, propagation, sampling, and export. Use Sentry's current interoperability documentation for the stable major version.

Problem: Too many traces are ingested

Cause: verification sampling such as 1.0 was left enabled in a high-traffic production service.

Fix: choose a sampling strategy appropriate to traffic and diagnostic value. Monitor telemetry volume after rollout.

Problem: Trace names have very high cardinality

Cause: dynamic IDs, user values, or full URLs are used as span/transaction names.

Fix: use route templates and stable operation names where the SDK/framework supports them. Put only safe, bounded dimensions into attributes.

Best Practices

Version-pin the tutorial and recheck on upgrade

Sentry's JavaScript SDK is moving quickly. Record the stable version used by the procedure and review migration notes before major upgrades.

Keep automatic instrumentation as the baseline

Use framework instrumentation for normal HTTP/database visibility; add manual spans only where they answer an important question.

Sample intentionally

Sampling is an observability design decision, not a setup checkbox. Balance diagnostic value, traffic, cost, and incident needs.

Avoid high-cardinality names

Stable route and operation names make traces searchable and aggregatable.

Protect telemetry data

Treat span attributes and trace context as production data with privacy/security implications.

Do not mix stable and prerelease guidance

As of September 10, 2026, v11 is beta. Use v10 stable behavior for production documentation until the stable release changes.

When This Setup Makes Sense

Sentry tracing is useful when you want to investigate:

• slow server requests;
• latency across framework/database/network spans;
• custom business-operation duration;
• error context inside a request; and
• performance regressions tied to application releases.

If your organization requires a vendor-neutral telemetry pipeline feeding multiple backends, OpenTelemetry may be the architectural center instead. Sentry can still participate, but the integration should be designed explicitly.

FAQ

Do I need @sentry/tracing for Node.js performance monitoring?

No. Modern Sentry Node SDKs include tracing support. The standalone @sentry/tracing package belongs to old SDK guidance and was removed from the modern package line.

Which Sentry version is current in this tutorial?

@sentry/node 10.74.0 was the npm latest release on September 10, 2026. Version 11.0.0-beta.2 was still tagged next.

What sampling rate should I use?

There is no universal rate. Use a high rate only for controlled verification if needed, then choose production sampling based on traffic, diagnostic value, and telemetry limits.

Why must Sentry load before Express?

Automatic instrumentation hooks supported modules as they load. Initializing Sentry after Express can prevent expected automatic tracing.

Do I need @sentry/opentelemetry?

Not for a normal current @sentry/node setup. It becomes relevant when you intentionally build/customize OpenTelemetry interoperability beyond the standard SDK behavior.

Conclusion

Current Sentry Node.js tracing is simpler than many old search results suggest: use the stable @sentry/node SDK, initialize it early, enable deliberate sampling, rely on automatic framework instrumentation, and add startSpan() only for important custom work.

The biggest maintenance risk is version drift. Do not copy @sentry/tracing, startTransaction(), or prerelease v11 behavior into a stable v10 production guide. Recheck the current package and migration notes whenever the major version changes.

For first-time error capture, use the sibling tutorial How to Set Up Sentry Error Monitoring in Node.js before enabling performance traces.

References

1. npm — "@sentry/node" — Sentry — https://www.npmjs.com/package/@sentry/node — accessed September 10, 2026; version 10.74.0 marked latest.
2. GitHub — "Official Sentry SDKs for JavaScript" — getsentry/sentry-javascript — https://github.com/getsentry/sentry-javascript — accessed September 10, 2026.
3. GitHub — "Upgrading from 7.x to 8.x" — getsentry/sentry-javascript — https://github.com/getsentry/sentry-javascript/blob/develop/docs/migration/v7-to-v8.md — accessed September 10, 2026; current historical reference for the modern span API transition and removal of old tracing patterns.
4. GitHub — "Sentry JavaScript SDK migration guide" — getsentry/sentry-javascript — https://github.com/getsentry/sentry-javascript/blob/develop/MIGRATION.md — accessed September 10, 2026; used to distinguish prerelease v11 interoperability changes from stable v10.
5. GitHub — "Official Sentry SDK for OpenTelemetry" — getsentry/sentry-javascript — https://github.com/getsentry/sentry-javascript/blob/develop/packages/opentelemetry/README.md — accessed September 10, 2026.