Sentry: tracesSampleRate 1.0 is a dev setting, not a production one

TL;DR

Enable spike protection per project (Settings > Spike Protection) so an anomaly cannot drain the quota in an hour. When one rate does not fit (health checks vs checkout flow), use the sampler callback instead of a flat rate.

When to use

You are seeing this: ``js tracesSampleRate: process.env.NODE\_ENV === "development" ? Use this skill when you run into "Sentry: tracesSampleRate 1.0 is a dev setting, not a production one".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 0.05-0.2. If you are on something much newer or older, the details may have shifted.

The shape to use

tracesSampleRate: process.env.NODE_ENV === "development" ? 1.0 : 0.1,

traces_sample_rate = 1.0 if os.environ.get("DEBUG") else 0.1

Start at 0.05-0.2 in production, watch the Usage stats page for a week, then tune. Sampling is probabilistic; low rates still catch recurring problems, they just take longer to reach significance.

Dynamic sampling

When one rate does not fit (health checks vs checkout flow), use the sampler callback instead of a flat rate. It receives context about the transaction and returns a float 0-1; returning 0 drops it. Keep the function cheap: it runs for every transaction.

• Python: traces_sampler
• JS: tracesSampler
• Laravel: traces_sampler option, or the SentryTracesSampleRate job middleware to lower the rate for specific queued jobs that would otherwise dominate volume

Know the zero semantics

• 0 = no new traces start (but incoming distributed traces from other services still continue).
• None/undefined (unset) = tracing fully disabled.

If transactions vanish after a config change, check you did not set 0 when you meant low, and remember v11 JS defaults to stream mode where ignoreTransactions no longer filters anything.

Backstops

Enable spike protection per project (Settings > Spike Protection) so an anomaly cannot drain the quota in an hour. It drops excess volume instead of billing it.

Why this matters

Every quickstart sets the sample rate to 1.0 so you see data immediately. In production, 1.0 means every transaction becomes a billed span. On a busy service that is the difference between a normal bill and an incident. Treat the docs example as scaffolding, not configuration.

Researched against live Sentry docs 2026-09-26. The Python options page (docs.sentry.io/platforms/python/configuration/options/) documents tracessamplerate semantics (0 = no new traces, None = tracing fully off, either it or tracessampler must be set to enable tracing) and tracessampler returning 0-1 with the samplingcontext. The Next.js guide (docs.sentry.io/platforms/javascript/guides/nextjs/) ships tracesSampleRate: NODEENV === development ? 1.0 : 0.1 as the wizard default. The Laravel guide (docs.sentry.io/platforms/php/guides/laravel/) carries the verbatim quota warning on SENTRYTRACESSAMPLE_RATE=1.0. The quotas page (docs.sentry.io/pricing/quotas/) lists Update your SDK sample rate among the quota-management actions and describes spike protection dropping excess volume.