Sentry release not showing data? What to check

When a Sentry release is missing or shows no health data, the cause is usually one of three things: the SDK is not sending sessions, the release name your SDK reports does not match the release you are looking at, or a filter is hiding the data. Check them in that order before changing your release pipeline.

Sentry creates a release automatically "the first time it sees an event with that release ID," according to its JavaScript release documentation. Release health then depends on session data from the same SDK. If either piece is missing or tagged differently, the release looks empty.

The checks below follow Sentry's documentation. Two of them also come from Specita's own synthetic Sentry test project, and we say so where they do. We have not reproduced every case on every platform.

Quick diagnosis

What you see	Most likely cause	First check
The release is not listed at all	No event or session has arrived with that exact release name	Compare the SDK's release value with the name you searched for
The release exists, but crash-free rates are empty	Session tracking is off, or the SDK is too old	Check your platform's release health settings and SDK version
Crash-free sessions appear, but crash-free users do not	The SDK has no user identity	Set the user when initializing the SDK
Data appears for one release name but not the one you created in CI	CLI and SDK use different names	Match the full name, including any package prefix and build number
The adoption chart is missing	Wrong project selection	Select exactly one project
Issue counts don't match crashed sessions	Expected behavior	Errors are sampled and filtered; sessions are not

1. Confirm the SDK sends sessions

Release health needs an SDK "configured to provide a release identifier and enable session tracking," as Sentry's release setup guide puts it. Many SDKs track sessions automatically once that is configured, but it can be turned off.

• JavaScript in the browser: sessions are tracked by default through the BrowserSession integration. If someone removed that integration, sessions stop.
• Apple platforms: Sentry says release health is captured by default from SDK version 6.0, with 5.0.0 as the minimum for health data. options.enableAutoSessionTracking = false turns it off.
• Other platforms: use the platform page linked from the release setup guide. Session models differ, so do not copy a setting from another SDK.

If events arrive but the release has no crash-free rate, session tracking is the first suspect.

2. Match the exact release name

This is the most common reason a release "exists" in one place and not in another. Sentry matches releases by the exact string.

Look at what each tool sends:

• Your SDK. On Apple platforms, if you do not set a name, the SDK builds one from the bundle identifier, version and build, such as my.project.name@2.3.12+1234, per Sentry's Apple release docs. In JavaScript, it is the release option you pass, for example my-project-name@2.3.12.
• Your CI. A step like sentry-cli releases new "$VERSION" creates a release with whatever $VERSION holds. If that is 2.3.12 while the app reports my.project.name@2.3.12+1234, you now have two different releases. Commits and deploys sit on one, sessions on the other.

Fix it by producing the name in one place and passing the same value to both the SDK and the CLI. Sentry also notes that releases are global per organization, so 1.0 from two different projects is the same release. Its CLI guide suggests unique names such as projectA-1.0.

From our test project: we sent controlled crashes from two release names that shared one grouped issue. The issue page mixed both releases, but filtering by the exact release showed 6 events for one name and 1 for the other. If you start from an issue, filter by the full release name before you conclude which release it affects.

3. Check environment and project filters

Session data carries release and environment tags. If you deploy to production but the SDK reports prod, or you are filtered to staging, the release can look empty.

Also check the project selection. Sentry says the adoption chart "does not display if you don't select a project or if you select multiple projects," and adoption stages appear only for mobile projects filtered to a single environment.

From our test project: when we linked exact time windows, the release health view used the pageStart, pageEnd and pageUtc URL parameters. Ordinary start and end parameters were dropped, so a bookmarked link showed a different window from the one we intended. If numbers look wrong, confirm the window on screen, not just in the URL.

4. Set a user for crash-free users

Crash-free sessions can work while crash-free users stay empty. Sentry's JavaScript documentation says that to receive user adoption data and the users crash-free rate, you set the user in initialScope when initializing the SDK.

If the user rate is missing or very low compared with the session count, check identity before anything else. Crash-free users vs crash-free sessions explains why the two rates differ.

5. Don't expect crash counts and crashed sessions to match

Sentry states that "the number of crashes is not expected to match the number of crashed sessions." Session data is sent unsampled and is not affected by inbound filters. Error events are subject to sampling, filters and quotas.

So a release can show crashed sessions with fewer matching issues, or the reverse. Abnormal sessions, where the SDK cannot tell whether a session ended cleanly, usually have no issue at all. This is expected, not missing data.

6. Give it a complete window

Sentry counts active sessions over the last 24 hours and recalculates adoption stages hourly. A release that started a few minutes ago may have very few sessions, and a rate based on a handful of sessions moves a lot with each crash.

Check the session count next to every rate. If it is small, wait for more traffic before deciding whether the release is healthy.

A release naming habit that prevents most of this

1. Generate one release name in CI, for example app-name@version+build.
2. Pass it to the SDK at build time and to every sentry-cli releases command.
3. Use the same environment names in the SDK and in deploy notifications.
4. Finalize the release as part of your release automation.
5. After deploying, open the release in Sentry and confirm sessions are arriving before you rely on its health numbers.

Connecting Sentry release data to Specita

Specita reads Sentry runtime evidence for an exact SDK release and environment. You link the full SDK release tag to a delivery in Specita. It does not guess from a display version. If the tag or environment is missing, Specita shows the evidence as unknown rather than healthy. The Sentry setup guide lists the read-only permissions and the steps.