Sentry PHP 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: composer require sentry/sentry
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.

\Sentry\init([
    'dsn' => 'https://[email protected]/1',
    'release' => 'checkout-api@' . getenv('GIT_SHA'), // service@commit
    'environment' => 'production',
    'traces_sample_rate' => 0.2,
    'profiles_sample_rate' => 0.2, // needs the excimer extension
    'enable_logs' => true,
]);

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/sentry 4.34.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 exception listener, marked unhandled, and sent on shutdown. Laravel and Symfony use `sentry/sentry-laravel` and `sentry/sentry-symfony`, which wrap this SDK (not part of this test).
Stack frames, in_app, source lines	Yes. Frames carry in_app (set `in_app_exclude` to your vendor folder) and five lines of source around each frame.
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` and the excimer extension: each transaction's profile is a flame graph linked from its trace.

Good to know

Call \Sentry\logger()->flush() at the end of a CLI script so structured logs are sent before it exits.
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 →