Make Sentry Performance Explain Business Latency With Targeted Spans

The problem: a slow request with no explanation

An invoice endpoint returns in seconds and the logs only say it is slow. That tells you the transaction is slow, not why. In Sentry, a transaction represents one unit of work such as an HTTP request or background job. Child spans describe the operations inside it, like database queries, outbound HTTP calls, or custom timed sections. The useful takeaway: keep auto-instrumentation for framework noise, add a few stable manual spans for business logic, and let sampling control cost.

Enable tracing with sampling as a cost control

Most Sentry SDKs auto-instrument popular frameworks and libraries. The exact integrations and defaults vary by platform and SDK version, so check the documentation for the SDK version you have installed before assuming coverage.

Sampling is the main cost control. A traces sample rate below 1.0 reduces volume and overhead. A rate of 1.0 is useful temporarily in staging or during an incident investigation.

Initialize the SDK with a DSN and a conservative sample rate. Run this in your application entry point, with permission to set environment configuration and access to the DSN.

// Node example, run in app entry
Sentry.init({
  dsn: 'YOUR_DSN',
  tracesSampleRate: 0.1
})

Verify by sending several requests to a test app and confirming transactions appear in the Performance view. Then lower the sample rate to zero temporarily and confirm new transactions stop arriving, and restore it. This proves sampling controls ingestion as expected.

Add a manual span for the business operation that matters

Auto-instrumentation shows framework spans. Manual instrumentation is the practical decision point. Wrap the code path that matters, such as a PDF render, billing call, or cache rebuild, so the waterfall explains business-level latency rather than only framework noise.

Keep span names stable and avoid high-cardinality values like user IDs in names. Do not put personally identifiable data or unbounded tags on spans.

Worked example: an Express endpoint that creates an invoice. Wrap the billing function in a custom span named calculate_invoice.

// Node example
app.post('/invoices', async (req, res) => {
  await Sentry.startSpan({ name: 'calculate_invoice' }, async () => {
    const items = await db.query('SELECT ...')
    const total = billing.calculate(items)
    await paymentClient.charge(total)
    res.json({ ok: true })
  })
})

The exact span API differs across SDKs and versions, so confirm the call signature against your installed SDK. Trigger the route and verify the waterfall shows the calculate_invoice span separately from database and HTTP spans. The relative durations tell you whether latency lives in the business calculation, the database, or the outbound payment call.

Read the waterfall and connect errors to traces

The waterfall visualizes parent transaction time against child span durations. When a transaction contains or ends near an exception, the Sentry issue and trace context can be inspected together, shortening the path from slow request to failing dependency.

To check this, trigger a handled exception inside the traced route and confirm the error event links back to the trace context for the same request.

Trade-offs and limitations

Sampling can hide rare slow paths. If a problem is intermittent, temporarily raise sampling for a route or add explicit spans around the suspected operation.

Overhead depends on SDK, framework, traffic, and integrations. Do not assume a fixed latency number without measuring in your own service.

High-cardinality span names, unbounded tags, or PII in breadcrumbs create noise, cost, and privacy risk. Keep span names stable and scrub sensitive fields.

Actionable next step: set a conservative traces sample rate in production, add one manual span around a critical business operation, and compare its duration to auto-instrumented DB and HTTP spans in the waterfall. Raise sampling only for the scope you are actively investigating.