Monitor the health of releases by observing user adoption, usage of the application, percentage of crashes, and session data. Release health provides insight into the impact of crashes and bugs related to user experience and reveals trends with each new issue through the release details, graphs, and filters.
Many SDKs automatically manage the start and end of sessions when the SDK is initialized, but release health configuration is key to ensuring you are receiving useful data, so check our information on which SDKs support release health for links to configuring the SDK, as needed.
Once you configure your SDK, Sentry connects the data to the specific release of your application and the associated code.
The primary component Sentry uses to monitor health is a session, which represents the interaction between the user and the application.
A session begins with the start of the application. Or, it begins with bringing the already started application back from background to the foreground.
A session ends with the closing of the application or with the application being sent to the background. If the application is in the background for less than 30 seconds, we do not start the session again. Applications that are active even on the background (for example, a music player) should track the sessions manually for the background process.
Sessions are submitted to Sentry so you can track the usage and adoption of your application. When a user of your application experiences a crash, error, or abnormal exit, the session will be flagged accordingly, and Sentry calculates derived metrics. The metrics include data such as the number of users that didn't experience a crash in the specified time range.
Users who started the application at least once in the last 24 hours.
The app had an explicit unhandled error or hard crash. You'll typically be able to view the corresponding issue in sentry.io that captures this event, and errors that did not cause the end of the application should not be included. To search for them in Discover or on the Issues page, filter by
error.unhandled:true . The number of unhandled events is not expected to match the number of crashed sessions because sessions are not subject to Inbound Filters or Sampling.
Percentage of distinct users who did not experience a crash during the specified time period.
Percentage of sessions in the specified time range not ended by a crash of the application.
Number of users that experienced a crash in the specified time range.
Depending on the selected display option, we show either:
- Session adoption: the number of sessions of a specific release in the last 24 hours.
- User based adoption: the number of users who started the application at least once during the last 24 hours of a specific release.
Adoption in the progress bar is calculated as a percentage of last 24 hour users/sessions in this release vs all releases in the project.
A shorter version of the name = name without the package or short version of the hash.
The application timed out, froze, or was forced to quit by the operating system. There is usually no corresponding Sentry issue, as this is a passive action.
The app shut down normally, but the session experienced handled errors. Typically, you'll be able to view any issues/errors in sentry.io.
The session ends normally and no errors occurred during its lifetime.
Learn more on these pages: