Disable Sentry tracing when the SDK points at Epure

Set the traces sample rate to 0 on the official Sentry SDK you already ship. JavaScript and TypeScript use tracesSampleRate. Python, Ruby, and PHP use traces_sample_rate. Go uses TracesSampleRate. Java calls setTracesSampleRate. .NET sets TracesSampleRate. On Sentry JS v8 and later, also set enableTracing: false when that option exists. Epure discards transaction envelope items. Distributed tracing is out of scope. Exception events land in Issues when the envelope includes an event item. The JS CI pin on this site is @sentry/browser and @sentry/node 7.120.0.

Wrong then right (Node)

Wrong: leave a non-zero sample rate from a suite template.

• import * as Sentry from "@sentry/node";
• Sentry.init({ dsn: process.env.SENTRY_DSN, tracesSampleRate: 0.2 });

Right: zero traces (and profiles if unused) in the same init.

• import * as Sentry from "@sentry/node";
• Sentry.init({ dsn: process.env.SENTRY_DSN, tracesSampleRate: 0, profilesSampleRate: 0 });

One Sentry.init. One DSN. No half-wired NodeClient. The client still builds spans when the rate is above 0 even though Epure will discard the transaction item. That is wasted CPU and, on dual-send, a metered span on Sentry Cloud.

Wrong then right (Python)

Wrong: sentry_sdk.init(dsn=dsn, traces_sample_rate=0.1). Right: sentry_sdk.init(dsn=dsn, traces_sample_rate=0.0). Keep DjangoIntegration / FastAPIIntegration if you already use them. Only the sample rate changes for this guide.

Wrong then right (Ruby)

• Sentry.init do |config|
• config.dsn = ENV.fetch("SENTRY_DSN")
• config.traces_sample_rate = 0.0
• end

Wrong is the same block with config.traces_sample_rate = 0.1 (or a leftover ENV default). Sidekiq processes need their own boot file zeroed. Web-only fixes leave background spans alive.

PHP / Go / Java / .NET

• PHP: \Sentry\init(['dsn' => getenv('SENTRY_DSN'), 'traces_sample_rate' => 0.0]);
• Go: sentry.Init(sentry.ClientOptions{ Dsn: os.Getenv("SENTRY_DSN"), TracesSampleRate: 0 }) then sentry.Flush before exit on short jobs
• Java: options.setDsn(...) then options.setTracesSampleRate(0.0) inside Sentry.init
• .NET: options.Dsn = ... then options.TracesSampleRate = 0.0 inside SentrySdk.Init

Keys table

Sentry JS v8+ also sets enableTracing: false when the option exists. Epure discards transaction items either way. Prefer zeroing the sample rate so the SDK stops building spans.

Concrete failure: dual-send still meters spans

Wrong: you pointed the primary DSN at Epure, saw Issues fill, and left a second transport or dual-send helper aimed at Sentry Cloud with tracesSampleRate: 0.2. Epure looked clean. The Cloud invoice still counted transactions. Right: rg -n "tracesSampleRate|traces_sample_rate|SENTRY_DSN|dsn:" across web, workers, and the dual-send helper. Zero every traces key. Remove or gate the Cloud DSN when you no longer need the soak window. Partial compatibility on Epure is not a license to keep shipping discarded item types to a suite host.

Concrete failure: Next.js edge left on

Wrong: zero @sentry/node in the Node server runtime and forget the Edge/client inits that @sentry/nextjs wires. Spans still leave the edge bundle. Right: open every Sentry.init the Next.js instrumentation creates (Node, Edge, client). Set tracesSampleRate: 0 in each. Pin @sentry/nextjs 7.120.0 when you match this site's CI line. Then verify with captureException, not with a trace waterfall UI that Epure does not have.

Prerequisites

Epure v0.1.5+ so official SDKs authenticate with the public key alone. Older binaries return 401 invalid_dsn. Fixture captures used elsewhere on this site: Ruby 5.18.0, PHP 4.8.0, Java 7.8.0, Go 0.28.0, .NET 4.9.0. Scope: exceptions. Replay and profiling: sibling guides with different narration shapes (Disable session replay, Disable profiling).

Verify

• Sentry.captureException(new Error("Epure verify test")) (or the runtime equivalent).
• Expect HTTP 202 and a body { "id": "<event-uuid>" }.
• Issues shows one unresolved row for that exception. Send it again and the count rises on the same issue.
• A mixed envelope can still return 202 while Epure discards the transaction item. An envelope with no event item returns 400 invalid_envelope.
• GET /health returns {"status":"ok"} before you blame the SDK.

Failure modes (wrong-then-right shape continues)

• You "disabled tracing" by removing exceptions too. Wrong. Keep captureException. Right: only zero the traces key.
• Web is zeroed, Sidekiq/Celery/worker still samples traces. Wrong: one process. Right: every entrypoint.
• Epure DSN is clean but Sentry Cloud DSN still samples spans on dual-send. Wrong: assume one init. Right: grep both DSNs.
• 401 / 202 empty Issues - not tracing-specific; use Invalid DSN and Events not showing.

Why zero beats "Epure will drop it"

Yes, Epure discards transaction items. The client still builds spans, serializes them, and pays CPU and network. On a dual-send to Sentry Cloud, those spans still meter. Zeroing the sample rate aligns client work with server scope and with the invoice you actually want.

Short jobs and Flush

Go CLIs and Lambda-style workers should Flush before exit so the last exception leaves the process after you zero traces. Losing the exception while debugging tracing config is a cruel irony. Keep the exception path boring.

Related mesh

Envelope for keep/drop tables. When error tracking is enough for the job decision. This guide stays procedural and wrong-then-right.