sentry-python: what the official Sentry SDK actually puts in your process

A two-dependency package that avoids pulling in your framework

The whole install is one command, taken from the README's Getting Started section:

pip install --upgrade sentry-sdk

The distribution on PyPI is called `sentry-sdk`, while the repository is `sentry-python`. That mismatch trips people up once. The package metadata in `setup.py` declares `python_requires=">=3.6"` and an `install_requires` list with exactly two entries: `urllib3>=1.26.11` and `certifi`. No requests, no framework, no logging shim.

That is the design decision that matters more than the feature list. Everything framework specific lives in `extras_require`, where Django, FastAPI, Celery, Falcon, aiohttp and roughly two dozen others each get their own optional install. A bare service that calls `sentry_sdk.init` ships two HTTP dependencies and nothing else, and a team that wants Django breadcrumbs pays for Django support only. The repository tree backs this up: the package is one directory, `sentry_sdk/`, with `tests/` beside it, `tox.ini` for the multi-environment test matrix and `uv.lock` pinning the development toolchain.

What a DSN does and why traces_sample_rate 1.0 is a demo value

Initialisation takes a DSN and a sampling rate, which is the whole configuration surface a small service needs:

import sentry_sdk

sentry_sdk.init(
    "https://[email protected]/1",  # Your DSN here
    traces_sample_rate=1.0,
)

The DSN is a URL carrying a public key, an organisation identifier and a project identifier. It is not a password: the same DSN appears in browser JavaScript that anyone can read from a page source, so it identifies the destination rather than authorising the sender.

The sampling rate deserves a second look. The README sets `traces_sample_rate` to 1.0 and comments that this captures 100% of traces for performance monitoring, which is the correct value while you are confirming instrumentation works and an expensive one to leave in place afterwards. Traces are the performance-monitoring feature, distinct from the exception events you get for free. Turning them on is not a cost-free decision, and the README does not tell you what the resulting bill looks like.

To confirm the pipeline end to end, the README gives a two-line check that needs no real failure:

import sentry_sdk
sentry_sdk.init(...)  # same as above

sentry_sdk.capture_message("Hello Sentry!")  # You'll see this in your Sentry dashboard.

raise ValueError("Oops, something went wrong!")  # This will create an error event in Sentry.

Integrations are the reason to pick this SDK over a logging handler

A generic error reporter attaches to your logging system and forwards what it finds. The SDK's argument is that the interesting context lives in framework internals, not in your log lines, and that reaching it means patching the framework.

The README names FastAPI, Django, Celery and OpenAI by name and links a full integration list on the documentation site. Each one is registered inside the same `init` call, as an object in the `integrations` list. That is how it works for a framework like FastAPI: the integration wraps the request handling path so that a failed request arrives as a span and a breadcrumb with the route, the method and the elapsed time attached, instead of a bare stack trace.

The release notes show how fast this surface moves. Version 2.70.0, published on 2026-09-22, added an integration for Mistral AI. Version 2.71.0, published on 2026-09-28, added one for TypeSafe and extended it across five pull requests to record `gen_ai.input.messages`, `gen_ai.output.messages` and `gen_ai.response.model`. The pattern is worth noticing because it says something about where the maintainers think demand is: a great deal of it is now about instrumenting LLM calls, with token usage attached as span attributes.

Version 2.69.2 from 2026-09-15 is a more typical patch, and its contents are a good argument for the package existing at all: a fix so a bottle serialisation loop cannot run forever, a change so ClickHouse query data only lands in a breadcrumb when sensitive data is opted into, a fix so pydantic-ai stops emitting tool execution spans when validation fails. These are library-specific bugs that nobody maintaining a logging integration would have found.

data_collection is the option to read before send_default_pii

Error reporting SDKs have a bad history of leaking request bodies and user records into a third-party dashboard by default. This one grew a dedicated answer to that, and the 2.70.0 release notes describe the new option as offering much more flexibility than `send_default_pii`, and as taking precedence over it when both are defined.

The axes are the interesting part. The option is a nested mapping, and the keys map to whole categories of data rather than to individual fields. The README shows the shape in a comment inside the init example:

    # data_collection={"user_info": False, "http_bodies": []},

The release notes for 2.70.0 spell out the rest of the key space: `user_info`, `gen_ai` with separate `inputs` and `outputs`, `graphql` with separate `document` and `variables`, `database_query_data`, `queues`, `http_bodies` as a list rather than a boolean, and `cookies` with a `mode` of `denylist` or an equivalent allowlist form and a `terms` list. An empty list for `http_bodies` is how you say send none.

The distinction between a boolean and a list is the part that reads as deliberate design. `http_bodies` as a list can name which content types to include, so you can forward JSON but not form posts, rather than choosing everything or nothing. The same fine-grained shape applies to GraphQL documents, which are frequently schema dumps rather than anything sensitive, and to database query data, which is usually safe until someone interpolates a parameter into it.

For an LLM-shaped application the `gen_ai` split matters most. Prompts and completions routinely contain whatever the user typed, and having `inputs` and `outputs` as separate switches means you can keep the call trace, the model name and the token counts while leaving the text behind. Version 2.69.2 tightened the adjacent path by making the ClickHouse driver only set `db.result` in a breadcrumb with sensitive data opt-in, which is the same principle applied to a different integration.

Two migration paths, and one of them is a different client library

The README carries two separate upgrade notes, and they are not equivalent. The first is `1.x` to `2.x`, described as significant upgrades and new features, with a migration guide linked on the documentation site and a `MIGRATION_GUIDE.md` in the repository root. The second is from `raven-python`, the previous client, which the README places in maintenance mode and points at a second migration guide.

The raven path is the one people forget, because raven was the original Python client for Sentry and plenty of installs still have it. Moving off a library that is in maintenance mode rather than deprecated is a small but real scheduling item: it is still receiving fixes, so nothing breaks, and it is also still not receiving features, so new Sentry capabilities will not reach it.

The 1.x to 2.x jump is the larger change and the one to read before touching a production install. A major version bump on an SDK that intercepts exceptions, patches framework internals and runs a background transport thread has a wider blast radius than a typical library upgrade, and the README does not enumerate the breaking changes itself. Both guides live on docs.sentry.io, not in the repository, so the practical sequence is to read the guide, diff your `init` call against the current one, and keep the old version pinned until the new one has shipped events you have checked.

Where the repository stops and the hosted service takes over

The repository is an SDK, and it is honest about being one. The README covers installation, one configuration example, a way to verify events arrive, a named list of integrations, two migration pointers and a licence. It then hands you to docs.sentry.io for everything that matters after that: sampling strategy, the full `data_collection` reference, PII scrubbing, release health, alerting and self-hosting. There is no guide to running Sentry itself in this tree.

That boundary is the most important thing to understand before choosing it. The SDK is MIT licensed and the `LICENSE` file says so plainly, so the code is free to read, fork and vendor. The event ingestion endpoint in the DSN is not. Self-hosting Sentry is a separate and considerably larger undertaking than vendoring this package, and nothing in `sentry_sdk/` helps with it.

The development setup tells you how seriously the project takes itself. `pyproject.toml` uses PEP 735 dependency groups, with `dev` installed by default and `typing` as an opt-in group, `tox.ini` drives the matrix, `renovate.json` handles dependency bumps, `pre-commit-config.yaml` gates commits and `codecov.yml` tracks coverage. There is also `AGENTS.md` and `CLAUDE.md` at the root, which tells you the maintainers have thought about how automated agents work in this codebase.

Activity is current. The last push was on 2026-09-28, the same day version 2.71.0 was published, and the 2.71.0 notes are real fixes such as keeping an event when a processor raises and isolating user callbacks so one bad handler cannot break the client. The 411 open issues are worth reading as context rather than as a verdict: for an SDK with this many integrations and a major version bump behind it, a large issue count is expected, and the release cadence is the better signal of whether the maintainers are keeping up.

Editorial conclusion

sentry-python is a good fit when you have already decided to use Sentry and want the Python side to be right, because the packaging is careful, the framework integrations are maintained alongside the core, and the data_collection option gives you a defensible answer about what leaves the process. It is the wrong shape of tool if you need vendor-neutral error reporting, since the DSN, the event format and the 411 open issues all point at one company's roadmap. Read the 1.x to 2.x migration guide before touching an existing install, set traces_sample_rate well below 1.0 outside development, and make your first configuration decision the data_collection dict rather than send_default_pii.

Frequently asked questions

Official sources

1. getsentry/sentry-python on GitHub
2. License: MIT
3. Project website
4. README
5. Releases