In Sentry, what does associating events with a release and its commit range buy you, and what does resolving an issue in the next release mean?

middleshould knowfreq 50%

answer

which deploy did this start in
old friend or new regression
stamped by the build, sent by the SDK
commits between two releases
resolved now, reopened only later

basics

~20 s

A release stamps events with the deployed version, so Sentry shows which deploy first produced an issue, marks a reappearance as a regression, and points at suspect commits. Resolving in the next release reopens the issue only if it recurs afterwards.

solid answer

~50 s

A release is a version string the SDK sends on every event, ideally a commit SHA or build number produced once by the pipeline. With it, Sentry can say which deploy an issue was first seen in -- the difference between a new regression and a familiar bug -- reopen a resolved issue automatically when it returns under a later release, match uploaded source maps or symbol files to the frames, and, given the release's commit range and a mapping from stack-frame paths to repository paths, put a short list of suspect commits and their authors on the issue. Resolving in the next release means the issue counts as resolved now and only events from a release created after this one reopen it, so the still-deployed old build does not instantly undo the resolution. All of it collapses if the identifier is reused between deploys.

A **release** is a version string the SDK sends on every event, ideally a commit SHA or build number produced once by the pipeline. With it, Sentry can say which deploy an issue was **first seen** in -- the difference between a new regression and a familiar bug -- reopen a resolved issue automatically when it returns under a later release, match uploaded source maps or symbol files to the frames, and, given the release's commit range and a mapping from stack-frame paths to repository paths, put a short list of **suspect commits** and their authors on the issue. Resolving *in the next release* means the issue counts as resolved now and only events from a release created after this one reopen it, so the still-deployed old build does not instantly undo the resolution. All of it collapses if the identifier is reused between deploys.

code

bash · 8 lines

bash

export SENTRY_RELEASE="[email protected]"

sentry-cli releases new "$SENTRY_RELEASE"
sentry-cli releases set-commits "$SENTRY_RELEASE" --auto
sentry-cli releases finalize "$SENTRY_RELEASE"

# the runtime must report the same string:
# Sentry.init({ release: process.env.SENTRY_RELEASE })

go deeper

for a junior

Be able to say what a Sentry release is -- the version string sent with every event -- and that it is how an issue page can tell you which deploy an error first appeared in rather than only when it last happened.

for a middle

Explain the pipeline end to end: the build creates the release, registers its commits, uploads artifacts under it, and the SDK reports the same string at runtime. Know what resolve-in-next-release means and how a regression is detected.

for a senior

Show that you have used it under pressure -- first-seen release to separate a new regression from a known bug, suspect commits to narrow a hunt to two authors -- and be able to diagnose an empty commit list or a failed artifact match.

for a principal

Own the identifier itself: decide the scheme, make one pipeline step produce it for every service, and be ready to argue what release health and deploy tracking are worth against the cost of wiring them across a whole estate.

What a Sentry release actually is

A release is a version identifier for the code that produced an event. It is not a timestamp and it is not a deploy: it is a string, ideally immutable and derived from the build -- a commit SHA, or something like [email protected]. It reaches Sentry from three directions, and they must agree:

the SDK sends it on every event, from the release option in Sentry.init or the SENTRY_RELEASE environment variable;
the build uploads mapping artifacts under it, so source maps or symbol files can be matched to frames;
a build step registers the release with Sentry and tells it which commits the release contains.

When those three agree, several features that look unrelated all switch on together.

What the association buys you

Feature	What it gives you	What it needs
First seen / last seen in release	"this started in 2026.09.06-3" -- new regression or old friend	the SDK sending `release`
Regression detection	a resolved issue that returns in a later release reopens itself	releases ordered by creation
Suspect commits	the few commits in that release touching files named in the stack trace	commit data on the release, plus a path mapping to the repository
Artifact matching	readable frames for minified or compiled code	artifacts uploaded under the same release
Release health	crash-free session and user rates per release	session tracking enabled in the SDK

The first row is what interviewers are really asking about. Without a release, an issue is a flat list of occurrences and you are guessing whether today's error is new. With one, "first seen in the release that went out an hour ago" is a fact, and that single fact is what turns an error monitor into a deploy-safety signal.

Suspect commits are the second-order payoff. Sentry knows the commits between the previous release and this one, and it knows which files the stack trace names; the intersection is a short list of commits, and their authors, that plausibly caused this issue. It is a heuristic, not a proof, and it collapses the moment the commit range is wrong -- a release created but never given commits, or a range spanning a fortnight because the previous release was never registered.

Resolving in the next release

Sentry's resolve action offers more than a plain "resolved":

Resolved. Closed now. Any later event for that issue reopens it as a regression.
Resolved in the next release. You have merged a fix that is not deployed yet. The issue counts as resolved, and only events arriving under a release created after the current one reopen it. Events still landing from the currently deployed build do not.
Resolved in a specific release. The same idea, anchored to a release you name -- useful when the fix has already gone out in a build you can point at.

That distinction exists because of a real annoyance: without it, merging a fix at 14:00 and resolving the issue means the issue reopens within seconds, because the old version is still serving traffic. The trade is that all of the semantics depend on the release identifier being ordered and immutable.

A deploy is a separate record saying that a given release reached a given environment at a given time. One release can be deployed to several environments, which is what lets Sentry tell an author that their fix actually reached production rather than merely being tagged.

Where it goes wrong

A reused identifier -- latest, or a branch name -- destroys all of it at once. There is no ordering, so first-seen is meaningless, regression detection cannot fire, resolve-in-next-release never triggers because there is no next release, and the commit range grows without bound.
A release set in the build but not at runtime, or the reverse. Artifacts land under a release no event ever reports, and symbolication fails silently while the release page looks populated.
Several services sharing one Sentry project with unrelated version schemes, so one service's deploy looks like a regression in another's issues, and suspect commits point into the wrong repository.
Commit data missing. Everything else still works; the suspect-commit list is simply always empty, and nobody notices until the day they need it.
A migration with two stacks live at once. During a mid-quarter move off a hosted vendor, the legacy and replacement paths must report distinct releases, or "first seen in this release" describes a build that only half the traffic is running.

Treat the release identifier as one value produced once by the pipeline and consumed by every step that talks to Sentry. It is a single line in three places, and everything on this list depends on those three lines matching.

## What a Sentry release actually is A **release** is a version identifier for the code that produced an event. It is not a timestamp and it is not a deploy: it is a string, ideally immutable and derived from the build -- a commit SHA, or something like `[email protected]`. It reaches Sentry from three directions, and they must agree: - the SDK sends it on every event, from the `release` option in `Sentry.init` or the `SENTRY_RELEASE` environment variable; - the build uploads mapping artifacts under it, so source maps or symbol files can be matched to frames; - a build step registers the release with Sentry and tells it which commits the release contains. When those three agree, several features that look unrelated all switch on together. ## What the association buys you | Feature | What it gives you | What it needs | | --- | --- | --- | | First seen / last seen in release | "this started in 2026.09.06-3" -- new regression or old friend | the SDK sending `release` | | Regression detection | a resolved issue that returns in a later release reopens itself | releases ordered by creation | | Suspect commits | the few commits in that release touching files named in the stack trace | commit data on the release, plus a path mapping to the repository | | Artifact matching | readable frames for minified or compiled code | artifacts uploaded under the same release | | Release health | crash-free session and user rates per release | session tracking enabled in the SDK | The first row is what interviewers are really asking about. Without a release, an issue is a flat list of occurrences and you are guessing whether today's error is new. With one, "first seen in the release that went out an hour ago" is a fact, and that single fact is what turns an error monitor into a deploy-safety signal. **Suspect commits** are the second-order payoff. Sentry knows the commits between the previous release and this one, and it knows which files the stack trace names; the intersection is a short list of commits, and their authors, that plausibly caused this issue. It is a heuristic, not a proof, and it collapses the moment the commit range is wrong -- a release created but never given commits, or a range spanning a fortnight because the previous release was never registered. ## Resolving in the next release Sentry's resolve action offers more than a plain "resolved": 1. **Resolved.** Closed now. Any later event for that issue reopens it as a **regression**. 2. **Resolved in the next release.** You have merged a fix that is not deployed yet. The issue counts as resolved, and only events arriving under a release created *after* the current one reopen it. Events still landing from the currently deployed build do not. 3. **Resolved in a specific release.** The same idea, anchored to a release you name -- useful when the fix has already gone out in a build you can point at. That distinction exists because of a real annoyance: without it, merging a fix at 14:00 and resolving the issue means the issue reopens within seconds, because the old version is still serving traffic. The trade is that all of the semantics depend on the release identifier being ordered and immutable. A **deploy** is a separate record saying that a given release reached a given environment at a given time. One release can be deployed to several environments, which is what lets Sentry tell an author that their fix actually reached production rather than merely being tagged. ## Where it goes wrong - **A reused identifier** -- `latest`, or a branch name -- destroys all of it at once. There is no ordering, so first-seen is meaningless, regression detection cannot fire, resolve-in-next-release never triggers because there is no next release, and the commit range grows without bound. - **A release set in the build but not at runtime**, or the reverse. Artifacts land under a release no event ever reports, and symbolication fails silently while the release page looks populated. - **Several services sharing one Sentry project** with unrelated version schemes, so one service's deploy looks like a regression in another's issues, and suspect commits point into the wrong repository. - **Commit data missing.** Everything else still works; the suspect-commit list is simply always empty, and nobody notices until the day they need it. - **A migration with two stacks live at once.** During a mid-quarter move off a hosted vendor, the legacy and replacement paths must report distinct releases, or "first seen in this release" describes a build that only half the traffic is running. Treat the release identifier as one value produced once by the pipeline and consumed by every step that talks to Sentry. It is a single line in three places, and everything on this list depends on those three lines matching.

What has to be configured before Sentry can show suspect commits on an issue?
Three things. A source-control integration so Sentry can read the repository; commit data associated with the release, so it knows the range this build contains; and a mapping between the file paths in your stack frames and the paths in the repository. Miss the last one and the release still lists its commits, but no commit is ever blamed for a specific issue -- the list is simply empty and nothing reports an error.
What is the difference between a Sentry release and a deploy?
A release is the version of the code: created once, given a commit range, finalized. A deploy is a record that this release reached a particular environment at a particular time, and one release can be deployed to several environments. Deploy records are what let Sentry tell an engineer that their fix has actually shipped to production rather than merely having been tagged in a build.
What breaks if every deploy reuses the same release identifier, such as `latest`?
Everything that depends on ordering. First-seen cannot distinguish deploys, regression detection has no later release to compare against, resolve-in-next-release never triggers because there is no next release, and the commit range grows without bound so suspect commits become useless. Use an immutable identifier -- a commit SHA or a build number -- and set the same value in the SDK, in the artifact upload and in the release registration.

saying these in an interview costs you the question

Uses a release identifier like `latest` that never changes between deploys
Thinks Sentry infers the release from the time an event arrived
Expects suspect commits without any repository integration configured
Treats resolve-in-next-release as a permanent dismissal of the issue
Sets the release in the build upload but not in the SDK at runtime

In Sentry, what does associating events with a release and its commit range buy you, and what does resolving an issue in the next release mean?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What a Sentry release actually is

What the association buys you

Resolving in the next release

Where it goes wrong

▾common follow-ups3 questions

▾red flags5 flags

What a Sentry release actually is

What the association buys you

Resolving in the next release

Where it goes wrong

answer

go deeper