Controlling Sentry Transaction Volume with tracesSampleRate and tracesSampler

Problem and takeaway

High-traffic frontend services often hit Sentry quota limits not because of errors, but because every page load and HTTP request is captured as a transaction. Without controlled sampling, teams pay for volume they don’t analyze, and trace coherence breaks when frontend and backend sampling rates mismatch.

Useful takeaway: you can route 100% of checkout flows, 5% of health checks, and 0% of noisy endpoints using tracesSampleRate and the tracesSampler callback, keeping quotas low while preserving trace context where it matters.

How Sentry sampling works

Sentry’s performance monitoring captures transactions (page loads, HTTP requests, background jobs) and the associated spans. Every captured transaction counts against your daily or monthly quota, so uncontrolled sampling on high-traffic services is the main cost driver.

The tracesSampleRate option sets a uniform sampling rate applied to all transactions. A value of 0.1 captures roughly 10% uniformly; 1.0 is appropriate for low-traffic backends but wasteful for busy frontends.

The tracesSampler callback receives a sampling context object with transactionName, url, and the parent sampling decision. Returning a rate between 0 and 1 lets you override the uniform rate per route, hostname, or transaction type.

// JavaScript SDK example
Sentry.init({
  dsn: "https://[contact removed]/123",
  tracesSampleRate: 0.2,           // baseline: capture 20% uniformly
  tracesSampler: async context => {
    // context.transactionName, context.url, context.parentSampled
    if (context.url.includes("/checkout")) return 1.0;      // always capture checkout
    if (context.url.includes("/health")) return 0.0;        // never capture health checks
    if (context.url.includes("/api/metrics")) return 0.01;   // sample 1% of metrics
    return undefined;                                       // fall back to tracesSampleRate
  },
});

Propagation and trace coherence

Sampling decisions propagate to downstream services via the sentry-trace and baggage headers. If a frontend transaction is sampled out, connected backend transactions that rely on that trace header may also be dropped, keeping the trace coherent but potentially shortening the observed path. Errors are captured independently of trace sampling: lowering tracesSampleRate does not reduce error events, but a sampled‑out transaction linked to an error may lose its full span context.

Concrete configuration example

Below is a Python SDK snippet that mirrors the same logic, showing how per‑route rates can be expressed for a typical web application:

# Python SDK example
import sentry_sdk

sentry_sdk.init(
    dsn="https://[contact removed]/123",
    traces_sample_rate=0.1,            # baseline 10% uniform rate
    traces_sampler=lambda context: None if context["transaction"].startswith("health")
                                     else 1.0 if "checkout" in context["transaction"]
                                     else 0.05,
)

Common mistakes and limits

• Frontend–backend mismatch. Setting tracesSampleRate only on the backend while the frontend SDK sends traces at 1.0, or vice versa, produces orphaned spans that appear broken in the trace view.
• Web Vitals distortion. If tracesSampler returns inconsistent rates between page load and navigation transactions, sampled transactions are not reweighted in dashboards, skewing Web Vitals distributions.
• Health‑check removal. Dropping health‑check transactions entirely via tracesSampler also removes them from release health and alerting baselines, which can mask real outages on those endpoints.
• SDK version sensitivity. Older SDKs used different option names (e.g., traces_sample_rate vs tracesSampleRate); confirm against your installed SDK version.

Practical verification

1. Initialize the SDK with tracesSampler logging each decision (e.g., console.debug inside the callback). Run representative traffic for at least one business day.
2. In Sentry’s Performance view, compare transaction counts per route against the intended ratios (e.g., checkout ≈ 100%, health ≈ 0%, API/metrics ≈ 1%).
3. Check Usage stats in Sentry settings after the traffic window; transaction volume should drop proportionally to the effective sample rate.
4. Trigger an error on a sampled‑out route and verify the error event arrives; note whether its trace context is partial, matching expectations.

Limitations

• Sampling rates are per‑SDK and do not automatically adjust for traffic spikes; you may need to re‑deploy or dynamically update the sampler function.
• Server‑side dynamic sampling on paid plans can boost rare transactions, but what reaches the server is still gated by the client‑side rate.
• Errors always arrive, but full trace context is only present when the linked transaction was sampled in.

By aligning tracesSampleRate with a targeted tracesSampler, you keep Sentry costs predictable while preserving the trace context that matters for your critical user journeys.