Sentry Python SDK with ZipLogger: setup and support

Set up

In ZipLogger, open Settings → API keys and create a key with Can read data unchecked. Copy the Sentry DSN shown under it (shown once, like the key).
Install the SDK: pip install sentry-sdk
Initialise it with that DSN. If you already use Sentry, only the DSN changes.

Set release to <service>@<git sha>. ZipLogger has no project per service: the part before @ is the service, and the SHA is the commit the regression engine blames from.

The DSN carries the key hex-encoded and always ends in /1. Point it at your workspace address (https://<workspace>.ziplogger.ai) or app.ziplogger.ai; both work.

import sentry_sdk

sentry_sdk.init(
    dsn="https://[email protected]/1",
    release=f"checkout-api@{GIT_SHA}",   # service@commit
    environment="production",
    traces_sample_rate=0.2,
    profiles_sample_rate=0.2,   # transaction profiles, linked to their trace
    enable_logs=True,           # sentry_sdk.logger
)

What arrives

The test sample captured the same error twice inside a POST /checkout transaction with a database span and an HTTP span, sent a warning message, two structured logs and a cron check-in pair, then crashed with an unhandled error. Each answer was read back through ZipLogger’s own API.

Signal	With sentry-sdk 2.72.0
Errors and Issues	Yes. `capture_exception` / `captureException` is an error line and an Issue; the same error twice is one Issue with two events, titled by the error type and culprit function.
Unhandled errors	Uncaught exceptions are reported by the SDK's excepthook integration, marked unhandled, and sent before the process exits. Web frameworks (Django, Flask, FastAPI) report theirs through their own integrations (not part of this test).
Stack frames, in_app, source lines	Yes. Frames carry the SDK's in_app flag and five lines of source around each frame, shown under the frame on the Issue page.
Breadcrumbs, tags, user, contexts	Yes. Shown on the Issue page; tags are searchable as `tag.<name>`, the user as `userId`.
Release and environment	Yes. `release: "checkout-api@3f9a2c1"` gives the service `checkout-api` and the commit `3f9a2c1`; the release is listed under Releases.
Tracing	Yes. The transaction and its child spans become a trace (server root, client children), and the service appears in APM within a minute or two. Errors inside the transaction link to it.
Structured logs	Yes. Logger records become log lines at their level, grouped by their message template.
Cron check-ins	Yes. Each check-in is a log line; with a `monitor_config` the heartbeat is created and its schedule kept in step. A failed or missed run opens an incident.
Profiling	Yes, with `profiles_sample_rate`: each transaction's profile is a flame graph linked from its trace. Continuous profiling (`profile_session_sample_rate`) also arrives, but its chunks are not linked to a trace yet.

Good to know

sentry_sdk.logger records keep their template (order {order_id} placed), so identical lines group the way native logs do.
Check-ins sent with capture_checkin or @monitor carry their own timestamp, so a check-in replayed from the offline cache is dated when it happened.
Not stored: replays recorded by the Sentry SDK, attachments, user feedback and client reports. The SDK gets a normal success answer for them. Past events stay in Sentry.

What carries over from Sentry, and what does not → · Sentry SDKs in the docs →