Sentry Ruby 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: bundle add sentry-ruby
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 do |config|
  config.dsn = "https://[email protected]/1"
  config.release = "checkout-api@#{ENV["GIT_SHA"]}" # service@commit
  config.environment = "production"
  config.traces_sample_rate = 0.2
  config.profiles_sample_rate = 0.2 # needs the stackprof gem
end

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-ruby 7.1.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	Through the SDK's integrations. The test raised through `Sentry::Rack::CaptureExceptions`, the middleware Rails and Sinatra apps get, and the error arrived marked unhandled with a transaction for its request; Rake and Sidekiq have integrations too (not part of this test). A plain Ruby script has no hook (sentry-ruby only flushes at exit): rescue, `Sentry.capture_exception`, re-raise.
Stack frames, in_app, source lines	Yes. Frames carry in_app 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 `stackprof` gem: each transaction's profile is a flame graph linked from its trace.

Good to know

sentry-ruby appends the class to the exception value (unknown sku 1 (PriceLookupError)), so that is how the Issue title reads.
Sentry.logger records (structured logs) are sent without extra configuration in 7.x.
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 →