Releases dashboard

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.

Identifying releases

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.

Stability score

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
Average stability score This release has a higher stability score than your target stability
Below average stability score The stability score of this release is between the target stability and critical stability
Low stability score This release has a lower stability score than your critical stability

What counts as a crash?

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.

Stability targets

For each project, you set the two stability targets you want to monitor

  • Target stability: This is the stability score that your team aims to exceed. Any score higher than this should mean that your app is in great shape and you should continue building new features for your users.
  • Critical stability: This critical stability target is the lower threshold of what is an acceptable stability score for your app. If you fall below this target, you’ll want to focus on fixing bugs to improve your app’s stability.


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
JavaScript (Browser) A page is loaded
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.

Source control

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.

Released by

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.