Compare the health of the releases of your application.
The releases dashboard is used to compare the health of releases of your application using the stability score and information about errors in each release. The stability score is available on the Standard plan.
Releases are automatically created from errors and sessions that are reported by your application. For example if an error is reported from version
1.0.0 of your application from the
production release stage, a release will be created for that version in Bugsnag.
Releases can be enriched with source control information and more by using a build tool integration.
The stability score shows you the percentage of user sessions in a release that were crash-free. The color indicates how this stability score compares to the targets you’ve set for your project.
|Stability score indicator||Definition|
|This release has a higher stability score than your target stability|
|The stability score of this release is between the target stability and critical stability|
|This release has a lower stability score than your critical stability|
Any session in which a user experiences an “unhandled” error is considered a crashing session and will impact the stability score. Different types of unhandled errors can cause different impacts on a user: usually it will mean the app has shut down completely but some unhandled errors on some platforms are recoverable.
It’s possible for a single session to have more than one unhandled error, but it will only count as one crashed session in the stability score.
For each project, you set the two stability targets you want to monitor
The adoption indicator shows how widely each release is being used.
The 10 bar graphic shows the proportion of sessions the release has seen out of all releases in the last 24 hours.
Your notifier must be configured to enable session tracking and see the stability score for your releases. See your platform’s docs for details.
Each notifier has it’s own default definition of a session. In general:
|Platform type||Session definition|
|Mobile||An app is opened|
|Server-side||A request is processed|
Alternatively you can provide your own definition of a session using the
sessionStart() function or equivalent for your platform.
Each release can link to your source control provider to show the code that was used to build a version and the changes from the previous version. To use this feature you will need to use a build tool integration.
Each release displays the person or entity who built the application. This can be useful to identify the ‘owner’ of a release. To use this feature you will need to use a build tool integration.
Other metadata that is relevant to a build can be seen on the detailed view of a release. This can be used to display any application specific information that is associated with a build, for example parameters that were used to build the application, and details of the changes contained in the build. To use this feature you will need to use a build tool integration.