Using Sentry Release Health to Catch Post‑Deploy Regressions

The problem: silent regressions after a deploy

When a new version ships, teams often rely on error counts or user reports to notice regressions. Small increases in crash‑free sessions or subtle latency bumps can go unnoticed until they affect a significant portion of users, leading to delayed fixes and poor experience.

Sentry’s release health feature addresses this by continuously measuring core health indicators—crash‑free sessions, error rate, and user‑feedback scores—for every released version and comparing them to a baseline derived from the previous stable release. If a metric deviates beyond a statistically significant threshold, the dashboard highlights the regression.

Enabling release health and alert thresholds

To use release health you must first ensure that each deploy is associated with a unique version tag. In Sentry project settings, toggle the "Release health" switch on. The feature then begins ingesting data from all SDKs that include the version context.

Next, define alert conditions on the health metrics you care about. For example, you might want to be notified if the error rate for a release exceeds the baseline by 20 % or if crash‑free sessions drop below 99 %. Alerts can be routed to Slack, email, or any integration supported by Sentry’s alerting service.

Where to run the version‑tagging command: In your CI/CD pipeline or local build script, after the artifact is built but before it is uploaded to Sentry, execute the Sentry CLI:

sentry-cli releases new @
sentry-cli releases set-commits @ --auto
sentry-cli releases set-version @ 
sentry-cli releases finalize @

Placeholders: replace with your Sentry project identifier (e.g., "my-org/my-app"), and with a unique string such as a git SHA or semantic version (e.g., "2026.10.04.1").

Permissions: The API token used must have the "project:releases write" and "org:release write" scopes.

Expected check: After the pipeline runs, open the Sentry UI → Releases page and verify that the new version appears with the correct tag and that commits are linked.

Risk: If the same version tag is reused or omitted, Sentry cannot establish a proper baseline, which may lead to missing regressions or false positives.

Worked example: spotting a crash‑rate regression

Imagine you deploy version "2026.10.04.1" of a mobile app. The previous stable release "2026.09.28.0" had a crash‑free session rate of 99.8 %. After the deploy, you notice a rise in crash reports in the Sentry error stream.

1. Open the Release health dashboard for "2026.10.04.1". The dashboard shows a baseline line (from "2026.09.28.0") and the current metric line for crash‑free sessions.
2. If the current line drops below the baseline by more than the configured threshold (e.g., 0.5 %), the health widget turns red and an alert is fired.
3. Click the metric to view the underlying events; you can filter by OS, device model, or app version to isolate the offending code path.
4. With the offending stack trace in hand, you create a hotfix, bump the version to "2026.10.04.2", and repeat the process.

This workflow turns a vague feeling of "more crashes" into a measurable, actionable signal.

Limitations and practical verification

Release health excels at detecting regressions that affect the tracked metrics (error rate, crash‑free sessions, user satisfaction). Subtle issues that do not change those numbers—such as a UI glitch that never throws an exception—will not surface unless you enrich the data with custom metrics or user‑feedback events.

To verify that release health is working as expected in a test environment:

1. Deploy two versions with distinct tags (e.g., "test.1.0" and "test.1.1").
2. In the newer version, intentionally raise the error rate by adding a temporary exception that fires on a known code path.
3. After a few minutes, check the Release health dashboard for "test.1.1". You should see the error‑rate metric diverge from the baseline and, if an alert is configured, receive a notification.

If the dashboard does not show a deviation, confirm that the version tag is present on incoming events (look at the event’s "release" field) and that the project’s release health toggle is enabled.

By coupling unique versioning with health‑based alerts, teams gain an early‑warning system that complements traditional error tracking and helps keep regressions from reaching users.