To set up releases in Sentry, configure your SDK with a release identifier and session tracking, upload source maps or debug files, associate commits through a repository integration, then notify Sentry of the deploy with sentry-cli. Release automation can handle the commit and deploy steps for you.
In Sentry, a release is a version of your code deployed to an environment. Telling Sentry about each one is what lets it spot new issues and regressions, tell you whether a fix landed, and show the health of a new deployment. Without releases, every error is just an error. With them, you can see which version broke what.
Do this before you deploy
Sentry recommends notifying it about a new release before you deploy. If you don't, it creates a release the first time it sees an event carrying that release identifier. That fallback is handy, but it's thin, as you'll see below.
Each release links to one or more projects. If several projects share a release, Sentry duplicates the release data for each one, which suits a front end and back end that ship together.
The four stages
1. Configure the SDK
Your SDK needs a release identifier and session tracking, and the environment must be set in the SDK too. Release health is supported for SDKs including Android, Flutter, iOS, JavaScript for browser and Node, Python, PHP, React Native, Rust and .NET.
2. Upload source maps or debug files
If your code is bundled, minified or compiled, upload source maps or the matching debug files so stack traces show your original source. This step also has to be done before suspect commits can be switched on.
3. Associate commits
Install a repository integration, or upload commit data manually through the API. Then configure your release script to associate commits with each release. You don't need a repository integration for the basic features, but Sentry recommends one as part of an automated setup.
4. Tell Sentry about the deploy
Without automation, you notify Sentry of a deploy with this command, using a token that's been set up for it:
sentry-cli releases --org ORGANIZATION_SLUG deploys VERSION new -e ENVIRONMENT
Release automation options handle both the commit association and the deploy notification, which is the route most teams settle on once the basics work. Finish the release if your automation doesn't already, then open Releases from Explore to see adoption and release health.
What you lose by letting Sentry guess
Sentry Docs explain that you can skip telling Sentry about a release, because it'll create one automatically from the first event it sees with that identifier. The catch is what doesn't happen. There's no commit association and no deploy record, so suspect commits and deploy emails stay off until you complete the later stages. You get version labels on errors, but not the who-changed-what that makes releases worth having.
What each stage switches on
| Feature | What you need in place |
|---|---|
| New issues and regressions per version | Release identifier in the SDK |
| Release health and adoption | Session tracking in the SDK |
| Readable stack traces | Source maps or debug files |
| Suspect commits | Source maps or debug files, plus associated commits |
| Emails to committers on a new environment | Associated commits and a deploy notification |
That last one is useful: when you deploy a release to a new environment, Sentry can email the people who committed to it, so the right developers hear about problems first.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Resolving issues against releases
You can resolve an issue in the current release, the next release or a specific commit. Resolving in a commit waits for a release containing that commit. If the error comes back after that, Sentry marks it as a regression, which is exactly the signal you want.
How BugSnag and Rollbar track releases
BugSnag's docs say configuring your notifier with your app version and release stage lets you filter the dashboard by release. Rollbar shows the commits in each deploy when a project is connected to a git repository, and highlights merged commits that haven't been deployed yet.
My advice for your first Sentry release
Do all four stages once, by hand, on a small project. Seeing suspect commits and deploy emails work end to end makes it obvious why the later stages matter. Then move the commit and deploy steps into your release automation so nobody has to remember them. If you're looking at the wider set of tools around your code, my guide to developer productivity tools that work and my list of GitHub alternatives are good next reads.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
What is a release in Sentry?
A version of your code deployed to an environment.
Must I create a release before deploying?
Sentry recommends it, but creates one automatically the first time it sees an event with that release identifier.
Do I need a repository integration?
Not for the basic features, though Sentry recommends one.
How do I tell Sentry about a deploy?
Use sentry-cli releases deploys with the version and environment, or the API.
Why upload source maps?
Bundled or minified code needs them for stack traces to show the original source.
