Workflow: release tracking from CI to triage

TL;DR

Check release health: crash-free rate and adoption tell you whether this is one unlucky user or a bad rollout. An alert rule for "new issue in the latest release" routes fresh breakage to the deploying team immediately, while they still remember what they shipped.

When to use

You are seeing this: A release in Sentry ties errors to the deploy that introduced them. Use this skill when you run into "Workflow: release tracking from CI to triage".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

A release in Sentry ties errors to the deploy that introduced them. Without it, every issue is timeless; with it, triage starts with "which release?" and often ends there.

1. Create the release in CI

Every production deploy runs:

sentry-cli releases new "[service]@[version]"
sentry-cli releases set-commits "[service]@[version]" --auto
sentry-cli releases finalize "[service]@[version]"

--auto associates the commits since the previous release. Finalize after the deploy succeeds, so a rolled-back deploy never looks like the current release.

2. Match the SDK's release string

The SDK's release option must equal the CLI's release name exactly. Derive both from the same CI variable. A mismatch means errors land on a phantom release with no commits and no artifacts.

3. Ship artifacts with the release

Upload source maps (or debug files for native) against the same release before finalizing. The release page becomes one place with commits, artifacts, and the errors they produced.

4. Triage with the release view

When a new issue appears after a deploy:

1. Open the issue's release. The suspect commits are right there.
2. The commit author is the first person to loop in, before broadcast triage.
3. Check release health: crash-free rate and adoption tell you whether this is one unlucky user or a bad rollout.
4. If it is a bad rollout, the release view shows exactly which deploy to roll back.

5. Alert on new issues per release

An alert rule for "new issue in the latest release" routes fresh breakage to the deploying team immediately, while they still remember what they shipped.

Verify

Pick the last three production deploys: each has a release page with commits, artifacts, and linked issues. The on-call engineer can name the suspect commit for the latest issue without opening the repo.

Researched against live Sentry docs 2026-09-26. The releases product page (docs.sentry.io/product/releases/) documents release creation, commit association, and deploy tracking. The CLI configuration page documents auth for CI. The ownership rules page (docs.sentry.io/product/issues/ownership-rules/) documents assignment semantics used in triage.