Keep sentry-java and its calls; change the DSN. Tested end to end on 2026-10-21 with
sentry-java 8.61.0 on Java 21 (profiler: sentry-async-profiler 8.61.0): every row
below is what that run stored and showed.
implementation("io.sentry:sentry:8.61.0")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(options -> {
options.setDsn("https://[email protected]/1");
options.setRelease("checkout-api@" + gitSha); // service@commit
options.setEnvironment("production");
options.setTracesSampleRate(0.2);
options.addInAppInclude("com.example"); // your packages
options.getLogs().setEnabled(true); // Sentry.logger()
});
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-java 8.61.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 UncaughtExceptionHandler integration (level fatal, marked unhandled) and flushed before the JVM exits. With Spring Boot, sentry-spring-boot-starter-jakarta also reports request errors and creates the transactions (not part of this test). |
| Stack frames, in_app, source lines | Frames and in_app, yes (set addInAppInclude to your packages). Source lines, no: the JVM SDK sends them only from source bundles uploaded to Sentry, which ZipLogger does not accept. |
| 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 | Partly. The JVM profiler (sentry-async-profiler, with setProfileSessionSampleRate) sends continuous profiles: flame graphs per service and time range, not linked to a single trace yet. |
What carries over from Sentry, and what does not → · Sentry SDKs in the docs →