Release health
Issues tell you what broke. Release health tells you how many of your users it hit, and whether the release you just shipped is better or worse than the last one.
It is built from sessions: the SDK opens one when the app comes to the foreground (or a request starts, on a server), and closes it with a status. Errora aggregates them per release on the Releases page.
Prerequisites
- A
releaseon every event. The mobile SDKs set it for you —<package>@<versionName>+<versionCode>on Android,<bundleId>@<version>+<build>on iOS. Elsewhere, setreleasein the SDK init. - Session tracking on. It is on by default in the mobile SDKs
(
enableAutoSessionTracking) and the browser SDK; don't turn it off.
Sessions are never sampled, spike-limited or billed: they are small, and a crash-free rate computed over a sample would be wrong.
Session statuses
| Status | Meaning |
|---|---|
| Healthy | Ended normally, no error |
| Errored | At least one error was captured during the session, but the app didn't crash |
| Crashed | Ended in an unhandled crash |
| Abnormal | Ended without the SDK being able to close it — the OS killed the app, or an ANR on Android |
Metrics
| Metric | Definition |
|---|---|
| Sessions / users | Sessions started, and distinct users (the SDK's user or installation id) |
| Crash-free sessions | 1 − crashed sessions / sessions |
| Crash-free users | 1 − users with a crashed session / users |
| ANR rate | users with an ANR / users — Android sessions that ended abnormally with anr_foreground or anr_background |
| Adoption | The release's share of all sessions in the selected window |
| Average session duration | Mean length of sessions that reported a duration |
| Errored / crashed / abnormal | Session counts per status |
The Releases page
Releases in the sidebar lists the releases that sent sessions, each with its adoption, crash-free sessions and users, session and user counts, errored/crashed/abnormal counts, ANR rate and average duration, with a chart of the selected window over time.
Filter by environment and period — 24h, 7d, 14d, 30d or 90d. A new release that loses crash-free users against the previous one is the signal to look at its issues.
Dropped by the SDK
SDKs also send client reports: counts of what they discarded before it reached Errora, with the reason. The Releases page shows them as Dropped by the SDK:
| Reason | Typical cause |
|---|---|
| Queue overflow | The SDK's send queue was full |
before_send | Your beforeSend callback returned null |
| Sample rate | Client-side sampling (sampleRate, tracesSampleRate) |
| Rate limits | The SDK was told to back off (429) |
| Network errors | The event couldn't be delivered |
Rising network errors on mobile are normal on poor connections; a rising before_send or
queue-overflow count usually means a configuration change.
Server-mode sessions
Server SDKs (Python, Node.js and others) don't send a session per request. In request
mode they send pre-aggregated session buckets (the sessions envelope item): per time
bucket, how many requests ended healthy, errored or crashed. Errora counts them into the
same session totals and crash-free rates. Aggregates carry no per-session duration, so only
individual sessions feed the average duration.
Troubleshooting
| Symptom | Cause / fix |
|---|---|
| The Releases page is empty | No sessions are arriving — session tracking is off, or release isn't set |
| ANR rate is always 0 on iOS | ANR rate is Android-only; iOS hangs show up as App Hang issues |
| Two releases for one build | The release string differs between platforms or builds — keep it consistent |