Using Sentry Release Health to Spot Regressions After Deployment

Enable release health in your application

The quickest way to see whether a new deployment introduced a regression is to let Sentry tag every error and performance event with a release identifier. When the tag is present on a sufficient share of events, Sentry aggregates error‑per‑session and crash‑free‑users metrics per release and surfaces a “New regressions” badge on the Release Health dashboard.

Node.js configuration example

// file: sentry.init.js
import * as Sentry from '@sentry/node';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  // The release string should match the version you just deployed
  release: 'my-app@1.2.3',
  environment: process.env.NODE_ENV || 'production',
  // Capture a representative sample of transactions; adjust based on traffic
  tracesSampleRate: 0.5,
});

module.exports = Sentry;

Place this initialization early in your application bootstrap (e.g., before starting the Express server). The release value must be identical for all instances of the service that belong to the same deployment.

How Sentry computes release health

Each event captured by the SDK includes the release tag. Sentry’s backend groups events by that tag and calculates:

• Error rate per session (or per user) for the release
• Crash‑free users percentage
• Apdex‑style performance scores if transactions are sampled

When a new release appears, Sentry compares its metrics to the baseline of the previous release (or a configurable rolling window). If the error rate exceeds a statistically derived threshold, the Release Health view shows a “New regressions” badge and highlights the spike in the error graph.

Limits and common pitfalls

Data quality requirements

For reliable aggregation, the release tag must be present on at least 80% of events. If the tag is missing or inconsistent (e.g., different strings across instances), Sentry falls back to unknown and the health metrics become inaccurate or disappear.

Plan‑dependent features

Basic error counts per release are available on the free tier. Advanced regression alerts, trend‑based baselines, and the ability to set custom thresholds require a paid plan (Team or Business).

Sampling considerations

Setting tracesSampleRate too high can quickly consume your event quota, especially in high‑traffic services. Adjust the rate so that the volume of sampled transactions stays within your plan’s limits while still giving a representative view of performance.

Self‑hosted version constraints

If you run a self‑hosted Sentry instance, ensure that the underlying Snuba and ClickHouse components are at version 20.10.0 or newer. Older releases lack the release‑health aggregation pipelines and will not display the metrics even if the SDK tags are correct.

Verifying the setup

1. After a deployment, go to Project Settings → Releases in the Sentry UI and confirm that the release name you supplied appears in the list.
2. Open any recent error or transaction detail view and verify that the release field shows the expected value (not unknown).
3. Navigate to Release Health for the project. You should see a graph for the new release; after a few minutes, error rates and crash‑free‑users numbers will populate.
4. If the new release’s error rate exceeds the baseline, a “New regressions” badge will appear at the top of the view. Clicking it opens a detailed comparison with the previous release.