Balancing Cost and Visibility: Sentry’s Transaction Sampling and Span Collection in Practice

Problem: Too Many Events, Too Little Insight

When a SaaS application scales, the volume of telemetry can explode. Every page load, API call, or background job may generate a transaction and dozens of spans. On Sentry’s hosted platform, this can quickly push the free tier limits and inflate costs. On a self‑hosted instance, excessive data burdens storage and query performance. Teams often wonder: how do I keep enough performance data to spot regressions without drowning in noise or paying for every single request?

Thesis: Use Transaction Sampling and Controlled Span Collection to Keep Costs Low While Retaining Diagnostic Power

Transaction sampling lets you capture a statistically representative slice of traffic, while span collection policies determine which sub‑operations are emitted. By tuning both knobs, you can maintain a high‑quality performance view and keep ingest rates within budget.

Understanding Transactions and Spans

Sentry models performance as a transaction that begins when a request enters the application and ends when the response is sent. Inside a transaction, the SDK records spans for discrete work units—database queries, external HTTP calls, cache lookups, etc. Each span carries a start and end timestamp, a name, and optional tags or metadata. The collection of spans gives you a granular timeline of where latency is spent.

In the UI, a transaction appears as a single row in the Performance view, with a bar chart showing its duration and a list of child spans. Errors are still captured independently; transaction sampling does not affect error ingestion.

Transaction Sampling in Sentry

Sampling is applied at the SDK level. The SDK checks the configured sampling rate before deciding whether to send a transaction. The default rate is 1 % (0.01). To change the rate, edit the project settings under Performance → Transaction Sampling:

Transaction Sampling:
  Default: 1%
  Custom Rules:
    - If environment == "production" AND user_id starts with "test" -> 0%
    - If request.path matches "/api/health" -> 100%

Dynamic sampling rules allow you to target high‑value traffic (e.g., production users) while ignoring low‑impact paths. The SDK evaluates the rule logic at runtime; no restart is required.

Span Collection Strategy

Even with a low transaction sample, you can control the granularity of spans:

• Automatic Span Collection – The SDK automatically instruments frameworks (Express, Django, etc.) and library calls (HTTP, database drivers). This is the simplest option but can generate many spans.
• Manual Span Creation – Use startSpan and finish to wrap custom code sections.
• Span Sampling – Sentry 2.0+ introduces tracesSampler and tracesSampleRate that can be overridden per transaction. You can also set tracesSampler to return a boolean for each span, effectively dropping low‑value spans.

Example: In a Node.js Express app, you might instrument only the database call and external API requests, skipping internal cache lookups.

const tracer = Sentry.getCurrentHub().getClient().getTracingClient();

app.get("/orders", async (req, res) => {
  const transaction = tracer.startTransaction({ name: "GET /orders" });
  const dbSpan = transaction.startChild({ op: "db", description: "SELECT orders" });
  const orders = await db.query("SELECT * FROM orders");
  dbSpan.finish();
  res.json(orders);
  transaction.finish();
});

Practical Example: 10 % Transaction Sampling with Span Filtering

Suppose your production environment sees 50 k requests per hour. A 1 % sample would give ~500 transactions—often too few to detect latency spikes. A 10 % sample yields ~5 k transactions, a sweet spot for most teams.

1. Set the sampling rate: In the project settings, change the default to 10 %.
2. Define a dynamic rule: Keep 100 % for health‑check endpoints to debug uptime issues.
3. Filter spans: In the SDK config, add a tracesSampler that returns false for spans tagged cache.

   const Sentry = require("@sentry/node");
   Sentry.init({
     dsn: "",
     tracesSampleRate: 0.1,
     tracesSampler: (samplingContext) => {
       const span = samplingContext.span;
       if (span.op === "cache") return false;
       return true;
     },
   });
   

4. Verify: After a few hours, check the Performance Overview to confirm ~5 k transactions per hour and a reduced number of cache spans.

Trade‑offs and Limitations

• Rare Latency Outliers – With aggressive sampling, a single slow request may not be captured. If your SLA requires detection of 99.9 % latency, consider a higher sample rate or a dedicated “slow‑path” rule.
• Span Granularity – Dropping spans can hide the root cause of a slow transaction. Use span filtering judiciously, focusing on low‑value operations.
• Self‑hosted vs SaaS – Self‑hosted instances may not support the latest sampling APIs until a recent upgrade. Verify your Sentry version (≥ 2.3) before applying tracesSampler.
• Cost vs Visibility – The cost of ingesting transactions is roughly proportional to the number of events. A 10 % sample may still be expensive for a 100 k request app; monitor the Event Count metric in the project settings.

Actionable Takeaways

1. Start with a 1 % default transaction sample and increase in 5 % increments while monitoring cost and performance visibility.
2. Use dynamic sampling rules to ensure critical traffic (e.g., production users, health checks) is always captured.
3. Apply span filtering to drop low‑value operations, but keep a small set of representative spans (DB, HTTP) for latency analysis.
4. Regularly review the Performance Overview to detect if a sampling rate is too low—look for sudden drops in transaction count or missing latency trends.
5. Document your sampling strategy in the team wiki; this helps new engineers understand why certain data is present or missing.

By tuning transaction sampling and span collection together, you can keep Sentry’s performance data manageable, cost‑effective, and diagnostically useful.