How to Track Release Health in Sentry (Crash-Free Sessions and Adoption)
Error counts alone do not tell you whether a release is healthy. A release with a hundred errors might affect three users or thirty thousand. Release health in Sentry adds the denominator: how many sessions and users are on each release, and what share of them experienced a crash.
This guide covers configuring releases and session tracking, reading crash-free rates and adoption, associating commits so you can trace problems to code, and setting alerts on unhealthy releases. It is useful for engineering leads and for PMs who want a reliable signal on whether a launch went well.
Have a feature in mind? Describe it and Vantage drafts the PRD.
A few sentences is enough: the problem, who has it and what you want to change. Vantage turns it into a structured PRD with requirements you can edit.
How this works
- We save what you typed. No AI runs on this page.
- You create a free account.
- Vantage builds a PRD from it inside your own workspace.
Why ask for an account? We’re a small team, and a full generation runs a multi-step AI pipeline that costs us real money. So we tie it to a free account instead of running it anonymously. You also get to keep the result and edit it.
Your text is only used to create your project, and it stays private to your account. If you don’t sign up, we delete it after 7 days. Privacy policy
Step-by-step guide
Set the release in your SDK
Release health depends on events and sessions being tagged with a release identifier. Configure the release option in your Sentry SDK, using a value that matches your deploy, such as a version number or commit SHA. Use the same identifier in every place you create the release in Sentry.
- Choose a release naming convention, such as app@1.4.2 or a commit SHA
- Set the release option in the SDK configuration
- Set the environment option, such as production or staging
Enable session tracking
Sessions are what make crash-free rates possible. Many Sentry SDKs, including browser and mobile SDKs, track sessions by default, but check your SDK's documentation and configuration to confirm. Without sessions, Sentry can show errors per release but not the share of sessions that were healthy.
Create releases and associate commits
Use the Sentry CLI or your CI integration to create a release when you deploy and associate commits with it. Associated commits let Sentry suggest which commit likely introduced an issue and who authored it. Mark the release as deployed to the right environment.
- Add release creation to your CI or deploy pipeline
- Associate commits using your repository integration
- Record deploys with the correct environment
- Upload source maps or debug files if your platform needs them
Read crash-free sessions and users
The Releases page shows crash-free session and crash-free user rates per release. Session rate tells you how often the app crashes during use. User rate tells you what share of people experienced a crash. Compare the new release with the previous one rather than looking at the number in isolation.
- Open Releases and select the project
- Compare crash-free rates between the latest and previous release
- Check whether new issues appeared in the latest release
- Look at both session and user rates
Track adoption
Adoption shows what share of sessions or users are on each release. A crash-free rate on a release with very low adoption is not yet meaningful. For mobile apps, adoption also tells you how quickly users are updating, which affects when you can retire old behavior.
Alert on unhealthy releases
Create metric alerts on crash-free session or user rate so the team is notified when a release drops below your threshold. Route alerts to the channel the release owner watches. Set thresholds based on your recent baseline rather than an arbitrary number.
Make release health part of launch reviews
For significant launches, include the release's crash-free rates and new issues in the launch review alongside product metrics. A feature that hits its adoption target but lowers crash-free users needs follow-up work.
Common mistakes
Inconsistent release names
If the SDK reports one release name and CI creates another, data splits across two releases. Use one convention everywhere.
Judging a release too early
Crash-free rates on a release with little adoption can swing widely. Wait until enough users are on the release.
Missing environment tags
Mixing staging and production data makes release health misleading. Always set the environment.
Tips
Use commit SHAs or semantic versions consistently as release identifiers.
Add release health to your post-deploy checklist for the first hour after deploy.
Set alert thresholds relative to your baseline crash-free rate.
Link the release in launch notes so PMs can check health directly.
How Vantage helps
Release health tells you whether what you shipped is stable. Vantage connects that back to intent: tickets trace to the PRD requirements they implement, and bi-directional sync with Linear shows what went into each release, so a drop in crash-free users can be traced to the requirement and re-planned.