# Sentry: errors arrive but transactions do not (or the reverse)
## They are independent pipelines
Error monitoring is always on once the SDK is initialized with a DSN. Tracing is opt-in and needs two things: a sample rate AND a transaction source. One working without the other is normal, not a contradiction.
## Errors yes, transactions no
1. **No sample rate set.** `traces_sample_rate`/`tracesSampleRate` unset means tracing is off entirely. This is the most common cause.
2. **No transaction source.** In Python, spans are only created inside an existing transaction; outside a supported framework you must create one with `start_transaction` (or `start_span` in newer versions). A plain script with a sample rate but no transaction produces nothing.
3. **Sample rate is 0.** Zero means no new traces start. Check for an env var overriding your config.
4. **v11 JS: filters referencing transactions.** `beforeSendTransaction` and `ignoreTransactions` no longer do anything in stream mode. If transactions vanished after upgrading, a filter did not break; the hook simply stopped being called.
## Transactions yes, errors no
This direction is rarer and usually means error events are filtered: `beforeSend` returning undefined, `ignoreErrors` matching too broadly, or inbound filters in project settings. Check client-side filtering before suspecting transport, since transport would break both.
## Confirmation
Set `debug: true`, trigger one error and one transaction, and watch the SDK logs: you will see the error envelope sent and either the transaction envelope sent, sampled out, or never created. Sampled-out vs never-created tells you whether the rate or the source is the problem.
## Verify
After the fix, both an issue and a trace for the same request should appear, linked together in the issue details. If they appear unlinked, the trace propagation headers are being stripped by a proxy between services.