# Release health

> https://docs.errora.org/en/products/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

1. **A `release` on every event.** The mobile SDKs set it for you —
   `<package>@<versionName>+<versionCode>` on [Android](/en/platforms/android),
   `<bundleId>@<version>+<build>` on [iOS](/en/platforms/apple-ios). Elsewhere, set `release`
   in the SDK init.
2. **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 |