Sentry SDKs · Java

Use the Sentry Java SDK with ZipLogger

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.

Get a DSN Moving from Sentry

Other languages: Python · Node.js · Go · Ruby · PHP · .NET

Set up

  1. 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).
  2. Install the SDK: implementation("io.sentry:sentry:8.61.0")
  3. 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(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()
});

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.

SignalWith 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.

Good to know

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