Turn off Sentry performance, replay and profiling but keep errors

Sentry's Next.js manual setup (checked 6 Nov 2026) starts you with tracesSampleRate at 0.1 in production and 1.0 in development, replaysSessionSampleRate: 0.1, replaysOnErrorSampleRate: 1.0 and a replayIntegration(). If you only ever open Issues, that is three products running for the one you use. This page turns each off per runtime, then proves two things: spans and replays stopped, and a test error still lands.

Does tracesSampleRate 0 turn off Sentry tracing?

Setting tracesSampleRate: 0 stops Sentry from starting new traces, but tracing stays switched on. In the JavaScript SDK, span recording is on whenever tracesSampleRate or tracesSampler is defined, and the check in @sentry/core is tracesSampleRate != null, so 0 counts as on. With tracing on, a sampled parent decision wins over your rate: Sentry's sampling precedence is tracesSampler, then the parent decision, then tracesSampleRate. A frontend at 0.1 can therefore keep a backend at 0 sending spans.

The off switch is deletion. The v8 SDK's own option comment tells you to "remove the tracesSampler and tracesSampleRate options" to disable performance monitoring. In v7 and v8 the SDK tested 'tracesSampleRate' in options, so even tracesSampleRate: undefined kept tracing on: delete the key. From v9, undefined counts as absent (v8 to v9 migration).

Zero is still workable when every runtime in the request path is at zero. Issues look the same either way. The difference shows in Stats: at 0, the SDK creates unsampled root spans and reports each one as a client discard with reason sample_rate. With the key deleted, it creates none. We read both behaviours in the SDK source on 6 Nov 2026.

How do you turn off Sentry tracing in Next.js but keep errors?

@sentry/nextjs initializes three times: instrumentation-client.ts for the browser (older setups use sentry.client.config.ts), sentry.server.config.ts for Node and sentry.edge.config.ts for the edge runtime, with the last two loaded from instrumentation.ts. Change all three in one commit. A server left at 0.1 keeps starting traces, and a runtime at 0 follows a sampled parent from another runtime. The Next.js client also adds browserTracingIntegration() by default (we checked the @sentry/nextjs 11.11.0 source), so deleting the rate is what stops it recording spans.

 // instrumentation-client.ts
 Sentry.init({
   dsn: "https://<key>@o<orgId>.ingest.sentry.io/<projectId>",
-  tracesSampleRate: process.env.NODE_ENV === "development" ? 1.0 : 0.1,
-  replaysSessionSampleRate: 0.1,
-  replaysOnErrorSampleRate: 1.0,
-  integrations: [Sentry.replayIntegration()],
 });

 // sentry.server.config.ts and sentry.edge.config.ts
 Sentry.init({
   dsn: "https://<key>@o<orgId>.ingest.sentry.io/<projectId>",
-  tracesSampleRate: process.env.NODE_ENV === "development" ? 1.0 : 0.1,
 });

Keep instrumentation.ts and its onRequestError export. That hook reports errors thrown while Next.js serves a request, and Sentry lists it as needing @sentry/nextjs 8.28.0 or later with Next.js 15. Deleting the rate stops spans, but the tracing code still ships in the browser bundle. To strip it, Sentry documents webpack.treeshake.removeTracing in withSentryConfig (tree-shaking options, checked 6 Nov 2026). Turn it on only when nothing in your code calls Sentry.startSpan().

How do you disable Sentry session replay but keep errors?

Sentry session replay runs only in the browser, so the switch lives in one file: instrumentation-client.ts for Next.js, or the Sentry.init of @sentry/browser, @sentry/react and the other browser SDKs. Setting replaysSessionSampleRate: 0 and replaysOnErrorSampleRate: 0 stops recording; Sentry documents 0 as collecting none for both. Removing replayIntegration() does the same and also takes the recorder out of the bundle every visitor downloads.

Watch the on-error rate. At 1.0, every session that hits an error records a replay, so a bad deploy multiplies replays exactly when errors spike. Sentry's pricing page lists 50 replays a month on the Team plan (checked 6 Nov 2026). Search for lazy loading as well: the Next.js replay guide adds replay later with Sentry.addIntegration(), so a clean init can still record. A search for replayIntegration, addIntegration and replaysOnErrorSampleRate across app/, src/ and shared packages finds every path.

How do you disable Sentry profiling?

Sentry profiling needs its own integration, so turning it off means removing that integration, not only a rate. In Node and the Next.js server, profiling comes from the @sentry/profiling-node package and nodeProfilingIntegration(); in the browser, from browserProfilingIntegration(). Since SDK 10.27.0 the rate is profileSessionSampleRate, default 0, paired with profileLifecycle set to 'manual' or 'trace'. Version 11 removed the older per-transaction options, profilesSampleRate and profilesSampler (v10 to v11 migration, checked 6 Nov 2026).

 // instrument.mjs
 import * as Sentry from "@sentry/node";
-import { nodeProfilingIntegration } from "@sentry/profiling-node";

 Sentry.init({
   dsn: process.env.SENTRY_DSN,
-  integrations: [nodeProfilingIntegration()],
-  tracesSampleRate: 1.0,
-  profileSessionSampleRate: 1.0,
-  profileLifecycle: "trace",
 });

Then run npm uninstall @sentry/profiling-node. Sentry's Node profiling page requires its version to match the main SDK exactly, which is one more pin to keep in step on every upgrade you no longer need.

How do you turn off Sentry tracing in Node.js?

@sentry/node reads one place besides your code: when tracesSampleRate is unset, it falls back to the SENTRY_TRACES_SAMPLE_RATE environment variable (we read getTracesSampleRate in the SDK source on 6 Nov 2026). Deleting the option from instrument.mjs while a host, a Docker image or a .env file still sets SENTRY_TRACES_SAMPLE_RATE=0.2 leaves tracing at 20%. The Next.js server runtime calls the same Node init, so the variable applies there as well.

Check every process that calls Sentry.init: the web server, each queue worker, cron scripts and one-off CLIs. Span usage follows instrumented work, not visitors. One request records several spans, and health checks and scheduled jobs record spans with nobody on the site, which is why a quiet app can still fill a span quota. A short-lived script should call await Sentry.flush(2000) before it exits so its last error is sent.

How do you turn off Sentry tracing in Python but keep errors?

Python's sentry-sdk disables tracing when both traces_sample_rate and traces_sampler are None, which is the default, so the clean fix is to delete them. Sentry's Python options page says 0 still continues traces that arrive from a JavaScript frontend, and recommends None to disable all tracing (checked 6 Nov 2026, SDK 2.74.0). The deprecated enable_tracing=True sets the rate to 1.0 when none is given, so remove that line too.

import os
import sentry_sdk

sentry_sdk.init(
    dsn=os.environ["SENTRY_DSN"],
    # no traces_sample_rate, traces_sampler or enable_tracing: tracing off
    # no profiles_sample_rate or profile_session_sample_rate: profiling off
)

Framework integrations for Django, Flask or Celery stay enabled; they report exceptions with tracing off. Profiling follows the same rule, since profiles_sample_rate, profiles_sampler and profile_session_sample_rate all default to None. Python logs are off unless you set enable_logs=True or an integration sets capture_sentry_logs.

Does Sentry send logs by default now?

Sentry JavaScript SDK 10.71.0, published on 24 August 2026, made enableLogs default to true, and its release notes give enableLogs: false as the opt-out. Version 11 removed the option: logs are sent whenever code calls Sentry.logger.* or you add a logging integration such as consoleLoggingIntegration(). On 10.71 to 10.x, add enableLogs: false. On v11, search for Sentry.logger and consoleLoggingIntegration and remove what you don't read.

How do you check in Sentry that spans and replays stopped?

Sentry's Stats page is the proof, because it counts what Sentry received per data category and outcome. Open Stats, then the Usage tab, and step through each billed category: errors, spans or transactions, replays, profiles and logs (quota docs, checked 6 Nov 2026). Set the range to the 24 hours after your deploy. Spans, replays and profile hours should drop to zero Accepted while errors keep their usual rate.

• Accepted spans after the deploy: a runtime still samples. Read the release on the newest span to find which one.
• Client Discard spans, no Accepted ones: a runtime runs at tracesSampleRate: 0. Nothing was sent; delete the key if you want the count gone.
• A trickle for a few hours: browser tabs opened before the deploy run the old bundle until they reload. The trickle should carry the previous release.
• Rate Limited errors: a separate problem with the error quota or spike protection, covered in what happens when the Sentry quota runs out.

Then prove the error path in staging. Call Sentry.captureException(new Error("errors-only check")), open the browser's Network panel, filter on envelope and read the header line of each item. {"type":"event"} is your error; there should be no transaction, replay_event or replay_recording items. The error should appear in Issues with its release and a readable stack.

Should you lower Sentry tracing instead of turning it off?

Lowering Sentry tracing beats turning it off when you still open traces to find slow requests. Sentry's pricing page lists 5,000,000 spans a month on the Team plan (checked 6 Nov 2026), so for many small apps spans cost nothing and the paid lines are replays and profile hours. Sentry's Next.js tracing troubleshooting shows a tracesSampler that samples health checks at a low rate; returning 0 for health and cron routes keeps the traces you read and drops the ones nobody opens.

Sentry.init({
  dsn: "https://<key>@o<orgId>.ingest.sentry.io/<projectId>",
  // tracesSampler wins over parent decisions and tracesSampleRate
  tracesSampler: ({ name }) => {
    if (name.includes("health") || name.includes("/api/cron")) return 0;
    return 0.05;
  },
});

Do the arithmetic before deciding: requests per month, times spans per request, times the rate, against the included 5,000,000. The Sentry pricing calculator does it with dated rates. If the answer is that you never open a trace, the settings above are the whole fix, and why a Sentry bill goes up covers the other meters.

What changes if you point the Sentry SDK at Epure instead?

Epure error tracking accepts the same Sentry SDK and keeps errors only: transactions, replays and profiles are dropped on ingest. One fixture in the Epure repository, an envelope from @sentry/profiling-node 10.56.0, carries a profile item next to an event item; Epure stores the event and drops the profile (SDK matrix). The settings above still matter with Epure, because a dropped span was still built in your process and uploaded from your users' browsers.

Moving is a DSN change, covered in move from Sentry to Epure without changing your SDK. Staying on Sentry with errors only is a sound end state too: Sentry's grouping, SDK coverage and hosted MCP are mature, and tracing stays one setting away. Epure vs Sentry compares both with dated prices, and when error tracking is enough helps you decide whether you need traces at all.

What if Sentry errors stop arriving after the change?

Sentry errors that stop after a tracing change nearly always come from an edit that touched more than tracing. Check three things in order. The DSN is still set in every runtime; a browser bundle that reads it from the environment needs a NEXT_PUBLIC_ variable, which Next.js inlines at build time. sampleRate (Python: sample_rate) is unset or 1. And instrumentation.ts still loads the server and edge configs and exports onRequestError. Rollback is a revert of the one commit; the old rates return on the next deploy.