Learn how to configure your SDK to tell Sentry about your releases.

A release is a version of your code that is deployed to an environment. When you give Sentry information about your releases, you can:

  • Determine issues and regressions introduced in a new release
  • Predict which commit caused an issue and who is likely responsible
  • Resolve issues by including the issue number in your commit message
  • Receive email notifications when your code gets deployed

Include the release when you initialize the SDK. The release name cannot:

  • contain newlines, tabulator characters, forward slashes(/) or back slashes(\)
  • be (in their entirety) period (.), double period (..), or space ( )
  • exceed 200 characters

The value can be arbitrary, but we recommend Semantic Versioning, Calendar Versioning, or the Git commit SHA.

Releases are global per organization; prefix them with something project-specific (such as "myapp@1.0.0") for easy differentiation.

The behavior of a few features depends on whether a project is using semantic or time-based versioning:

  • Regression detection
  • Data filtering by release:latest

We automatically detect whether a project is using semantic or time-based versioning.

import sentry_sdk

    # ...

    # By default the SDK will try to use the SENTRY_RELEASE
    # environment variable, or infer a git commit
    # SHA as release, however you may want to set
    # something more human-readable.

How you make the release available to your code is up to you. For example, you could use an environment variable that is set during the build process or during initial start-up.

If you do not set release in init(), the Sentry SDK will try to guess it. The SDK will first check for the environment variable, SENTRY_RELEASE. If this environment variable is not set, the SDK will then check if a Git repository is present and, if so, will take the Git SHA from the latest commit. If this doesn't work, the SDK will check for environment variables used by hosting providers like HEROKU_SLUG_COMMIT, SOURCE_VERSION, CODEBUILD_RESOLVED_SOURCE_VERSION, CIRCLE_SHA1, and GAE_DEPLOYMENT_ID.

We recommend that you tell Sentry about a new release before sending events with that release name, as this will unlock a few more features like identifying regressions and associating commits to releases. Learn more in our Releases documentation.

After configuring your SDK, you can install a repository integration or manually supply Sentry with your own commit metadata. Read our documentation about setting up releases for further information about integrations, associating commits, and telling Sentry when deploying releases.

Monitor the health of releases by observing user adoption, usage of the application, percentage of crashes, and session data. Release health will provide insight into the impact of crashes and bugs as it relates to user experience, and reveal trends with each new issue through the Release Details graphs and filters.

In order to monitor release health, the SDK sends sessions.

Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").