Sentry .NET 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: dotnet add package 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.

SentrySdk.Init(o =>
{
    o.Dsn = "https://[email protected]/1";
    o.Release = $"checkout-api@{gitSha}"; // service@commit
    o.Environment = "production";
    o.TracesSampleRate = 0.2;
});

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 6.12.1
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	Unhandled exceptions are reported by the SDK's AppDomain integration, marked unhandled, and flushed before the process exits. ASP.NET Core apps use `Sentry.AspNetCore` (`builder.WebHost.UseSentry(...)`), which also creates the request transactions (not part of this test).
Stack frames, in_app, source lines	Frames and in_app, yes. Source lines, no: the .NET SDK sends none (Sentry reads them from uploaded symbols).
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 `Sentry.Profiling` (`o.ProfilesSampleRate` and `o.AddIntegration(new ProfilingIntegration())`): each transaction's profile is a flame graph linked from its trace.

Good to know

Version 6 names each frame by its whole signature (int Shop.Lookup(string sku)). Before 2026-10-21 ZipLogger could not read those frames, so .NET Issues had no frames and grouped by message; they group by stack now.
For ZipLogger's own .NET logging there is also ZipLogger.Extensions.Logging; the Sentry SDK is the way to get errors, tracing and profiling from one package.
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 →