# Performance & tracing

> https://docs.errora.org/en/products/performance

Tracing answers "why was that request slow?" — which database call, which HTTP hop, which
LLM call ate the time.

## Setup

Turn on trace sampling in the SDK. Everything else (framework middleware, DB drivers, HTTP
clients) is instrumented automatically by the official SDKs.

```python
sentry_sdk.init(
    dsn="…",
    traces_sample_rate=0.2,        # 20% of requests
    environment="production",
    release="myapp@1.4.2",
)
```

```javascript
Sentry.init({
  dsn: "…",
  integrations: [Sentry.browserTracingIntegration()],
  tracesSampleRate: 0.2,
  tracePropagationTargets: ["localhost", /^https:\/\/api\.example\.com/],
});
```

### Sampling strategy

- Development: `1.0`.
- Production: start at `0.1`–`0.2`. Traces are billed per span
  ([Tracing service](/en/billing/wallet)), and a busy service produces a lot of them.
- Need precision on one endpoint? Use a `traces_sampler` function that returns `1.0` for the
  routes you care about and a low rate for health checks.

### Distributed tracing

To follow one request across services, the SDK propagates `sentry-trace` and `baggage`
headers. Set `trace_propagation_targets` (backend) / `tracePropagationTargets` (browser) to
include your own API hosts, and make sure your reverse proxy does not strip those headers.

## Custom spans

```python
with sentry_sdk.start_transaction(op="task", name="nightly-settlement") as tx:
    with tx.start_child(op="db.query", description="SELECT … FROM ledger"):
        rows = fetch_rows()
    with tx.start_child(op="http.client", description="POST /gateway/verify"):
        verify(rows)
```

## In the UI

**Performance** lists transactions for the selected project with:

- **Throughput** (events per period) and **latency** (avg, p50…p99)
- **Failure rate**
- Filters by environment, release, operation, time period and **user** — pick a person and the
  routes and jobs narrow to the ones they triggered (the same filter as on issues and logs;
  the **Users** page links straight into it)

Open a transaction to get the **trace waterfall**: every span with its duration, nesting and
tags, so you can see the serial database calls or the slow third-party hop directly.

Spans tagged `gen_ai.*` or `mcp.*` are additionally projected into
[AI monitoring](/en/products/insights).

## Dashboards

The `transactions` dataset is available to [dashboards](/en/products/dashboards) with
`count()`, `avg(duration)`, `sum(duration)`, `failure_rate()` and `p50`–`p99` percentiles,
grouped by transaction, op, status, environment, release or platform.

## Troubleshooting

| Symptom | Cause / fix |
| --- | --- |
| No transactions at all | `traces_sample_rate` is unset or `0` |
| Traces stop at the service boundary | Propagation targets don't include the callee, or a proxy strips `sentry-trace`/`baggage` |
| Browser transactions but no backend spans | The backend SDK isn't initialized, or its sample rate is much lower — a child inherits the parent's sampling decision only when the headers arrive |
| Costs climbing | Lower `traces_sample_rate`, or sample health-check routes to `0` with `traces_sampler` |