Releases & Health
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
Additionally, releases are used for applying source maps to minified JavaScript to view original, untransformed source code.
Bind the Version
Include a release ID (often called a "version") when you configure your client 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 either of these naming strategies:
- Semantic Versioning:
package@version
orpackage@version+build
(for example,my.project.name@2.3.12+1234
)package
is the unique identifier of the project/app (CFBundleIdentifier
on iOS,packageName
on Android)version
is the semver-like structure<major>.<minor?>.<patch?>.<revision?>-<prerelease?>
(CFBundleShortVersionString
on iOS,versionName
on Android)build
is the number that identifies an iteration of your app (CFBundleVersion
on iOS,versionCode
on Android)
- Commit SHA: If you use a DVCS, we recommend using the identifying hash (for example, the commit SHA,
da39a3ee5e6b4b0d3255bfef95601890afd80709
). You can let Sentry CLI automatically determine this hash for supported version control systems withsentry-cli releases propose-version
.
Releases are global per organization; prefix them with something project-specific for easy differentiation.
Sentry.init({
release: "my-project-name@2.3.12",
});
A common way to do this with would be to use the process.env.npm_package_version
like so:
Sentry.init({
release: "my-project-name@" + process.env.npm_package_version,
});
How you make the version available to your code is up to you. For example, you could use an environment variable that is set during the build process.
This tags each event with the release value. We recommend that you tell Sentry about a new release before deploying it, as this will unlock a few more features as discussed in our documentation about releases. But if you don’t, Sentry will automatically create a release entity in the system the first time it sees an event with that release ID.
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.
Release Health
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.
The SDK will automatically manage the start and end of the sessions when the SDK is initialized.
Release health on the server side is tracked in two different modes:
- Single sessions that represent a node process; for example, a CLI application. In single sessions mode, the SDK creates a session for every node process. A session is started on
init
of the SDK, and ends when the process is exited. - Session aggregates represent requests. In session aggregates mode, sessions will be recorded differently and will represent the lifetime of requests. For the SDK to be able to capture request mode sessions, you must enable the
requestHandler
of the express middleware.
// The request handler must be the first middleware on the app
app.use(Sentry.Handlers.requestHandler());
The SDK automatically determines which mode Release Health will operate in. By default, the SDK runs in single sessions mode. However, if the requestHandler
express middleware is enabled, Release Health is automatically toggled to session aggregates mode. If the requestHandler
express middleware is not enabled, session aggregates mode will not be enabled and sessions will represent the health of the web server application process if, for example, a web server application is being run.
We mark the session as crashed if an unhandled error reached our errorHandler
middleware.
We mark the session as an error if the SDK captures an event that contains an exception (this includes manually captured exceptions).
By default, the JavaScript SDKs are sending sessions, to disable this toggle the flag autoSessionTracking
to false
:
Sentry.init({
autoSessionTracking: false // default: true
});
- Package:
- npm:@sentry/node
- Version:
- 8.24.0
- Repository:
- https://github.com/getsentry/sentry-javascript