The Mobile Release Health dashboard

How each release is doing: crash-free sessions, adoption, stability by build, the web vitals, flaky requests, memory pressure, battery, thermal state and app exits.

Who it is for: Release managers and the engineers on a rollout: is the new build healthy, and is it reaching people?

Open it from Dashboards in the Observatory: choose Mobile Release Health. It is a built-in board, so it is read-only; Save a copy makes one you can change. How every panel reads the range, its colors and its empty states is on Reading a board.

The toolbar: the filters Build, Platform and Service, each All until you pick a value, and the time range. Each menu lists the values flutter.session.count carries in the range. Each panel below names the filters that narrow it.

[TODO: screenshot of the Mobile Release Health dashboard over the last 7 days, every filter All: Release health, Adoption with the Release comparison table, and Stability by build]

Release health

Crash-free sessions

The share of ended sessions that did not end in a crash. Abnormal ends are shown apart and do not count against it. It is a session figure, not a count of crashes: the Crashes list counts crashes. Keep it above 99.5%.

How it is computed: Crash-free sessions = 1 − crashed sessions / ended sessions, as a percent, the way Sentry counts it. Both come from flutter.session.count: an ended session is one whose session.status is ok, errored, unhandled, crashed or abnormal, and only crashed counts against the figure. A range whose sessions all ended without a crash reads 100%. One figure for the whole picked range.
Better: Higher is better.
Colors: The figure turns amber below 99.5% and red below 99%.
No session ended: when no session ended in the range, it shows this instead of a figure: No session end recorded in this range, so crash-free sessions can't be computed.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on flutter.session.count.

Sessions started

Sessions started: the denominator behind adoption and every rate on this page.

How it is computed: flutter.session.count where session.status is started. One figure for the whole picked range.
Better: Higher is better. Beside the figure, its change from the prior range of the same length: green when it moved the better way, red when it moved the other way.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on flutter.session.count.

Crashed sessions

Sessions that ended in a crash. Crash-free stays above target only when this stays near zero.

How it is computed: flutter.session.count where session.status is crashed. One figure for the whole picked range.
Better: Lower is better. Beside the figure, its change from the prior range of the same length: green when it moved the better way, red when it moved the other way.
Colors: The figure turns amber above 1 and red above 10.
No session ended: when no session ended in the range, it shows this instead of a figure: No session end recorded in this range, so crashed sessions can't be computed.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on flutter.session.count.

Sessions the SDK could not confirm ended gracefully (the device died, or the OS killed the app without a report), of all ended sessions.

How it is computed: flutter.session.count where session.status is abnormal, divided by ended sessions (ok, errored, unhandled, crashed or abnormal), as a percent. One figure for the whole picked range.
Better: Lower is better.
Colors: The figure turns amber above 1% and red above 3%.
No session ended: when no session ended in the range, it shows this instead of a figure: No session end recorded in this range, so abnormal sessions can't be computed.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on flutter.session.count.

Session outcomes

All ended sessions by outcome, stacked: ok, errored, unhandled, crashed, abnormal.

How it is computed: flutter.session.count for ended sessions, one stacked segment per session.status. Stacked bars, one per step across the picked range.
No session ended: when no session ended in the range, it shows this instead of a figure: No session end recorded in this range, so session outcomes can't be computed.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on flutter.session.count.

Adoption

Session starts per second by build

A healthy rollout shows the new build climbing while the old one fades.

How it is computed: The per-second rate of flutter.session.count where session.status is started, one line per build. Lines, one point per step across the picked range.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on flutter.session.count.

Release comparison

One row per build, whatever the Build filter, most sessions first. The crash-free target is 99.5%.

How it is computed: Sessions started: flutter.session.count where session.status is started, per build (app.build_id), the ten builds with the most. Crash-free sessions: 1 − crashed sessions / ended sessions. Crashed: crashed sessions. ANR exits: exits whose app.exit.reason is anr. Cold start p95: the 95th percentile of flutter.app.startup.duration for cold starts. A table, every figure for the whole picked range.
Filters: Platform and Service narrow it; Build does not.
Opens: its title opens the Metric screen on flutter.session.count.

Stability by build

Crash-free sessions by build

Crash-free sessions for the five builds carrying the most sessions, each step. Abnormal ends are shown apart. The dashed lines are the 99.5% and 99% targets.

How it is computed: Crash-free sessions per build (app.build_id): 1 − crashed sessions / ended sessions, as a percent, from flutter.session.count. Only crashed counts against it. Lines, one point per step across the picked range.
Colors: Dashed lines mark 99.5% (warn) and 99% (crit).
No session ended: when no session ended in the range, it shows this instead of a figure: No session end recorded in this range, so crash-free sessions by build can't be computed.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on flutter.session.count.

User experience (web vitals)

Largest contentful paint (p75)

Largest contentful paint at the 75th percentile, from your Flutter web app.

How it is computed: The 75th percentile of flutter.experience.lcp. One figure for the whole picked range.
Better: Lower is better.
Colors: The figure turns amber above 2.5 s and red above 4 s.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on flutter.experience.lcp.

Interaction to next paint (p75)

Interaction to next paint at the 75th percentile, from your Flutter web app.

How it is computed: The 75th percentile of flutter.experience.inp. One figure for the whole picked range.
Better: Lower is better.
Colors: The figure turns amber above 200 ms and red above 500 ms.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on flutter.experience.inp.

First contentful paint (p75)

First contentful paint at the 75th percentile, from your Flutter web app.

How it is computed: The 75th percentile of flutter.experience.fcp. One figure for the whole picked range.
Better: Lower is better.
Colors: The figure turns amber above 1.8 s and red above 3 s.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on flutter.experience.fcp.

LCP, INP and FCP p75 over time

Spikes correlate with rollouts; sustained regressions with backend or asset-size changes.

How it is computed: The 75th percentiles of flutter.experience.lcp, flutter.experience.inp and flutter.experience.fcp, one line each. Lines, one point per step across the picked range.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on flutter.experience.lcp.

Network flakiness

Flaky client requests

The share of client requests the SDK judged flaky. The flaky verdict, its reason and the connectivity are attributes of the HTTP client span.

How it is computed: Client spans with dartastic.network.flaky true, divided by all client spans, as a percent. One figure for the whole picked range.
Better: Lower is better.
Colors: The figure turns amber above 1% and red above 5%.
Filters: Build, Platform and Service narrow it.
Opens: its title opens Traces.

Flaky reasons

Flaky requests by the reason the SDK gave.

How it is computed: The client spans with dartastic.network.flaky true, counted per dartastic.network.flaky.reason. Slices of one whole, each figure for the whole picked range.
Filters: Build, Platform and Service narrow it.
Opens: its title opens Traces.

Flaky requests per minute by reason

Flaky requests over time, by reason.

How it is computed: The per-minute rate of client spans with dartastic.network.flaky true, one line per dartastic.network.flaky.reason. Lines, one point per step across the picked range.
Filters: Build, Platform and Service narrow it.
Opens: its title opens Traces.

Memory pressure and battery

Memory pressure level by platform

The highest level each step: onTrimMemory below Android 14 only, or 1 for an iOS memory warning.

How it is computed: The highest value of memory_pressure.level, one line per os.type. The levels: 1 is an iOS memory warning. Below Android 14, Android records 5, 10 and 15 (running moderate, running low, running critical) and 60 and 80 (background moderate, background complete). Since Android 14 (API level 34) Android sends none of these, so newer Android phones report nothing here: read Low-memory exits instead. UI hidden (20) and Background (40) are the app leaving the screen, not pressure, and are not recorded. Lines, one point per step across the picked range.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on memory_pressure.level.

Memory pressure events

An OS callback: iOS, or Android below 14. An app can also record its own. On newer Android, read Low-memory exits.

How it is computed: The total of memory_pressure.event over the time range. Below Android 14, Android labels its callbacks running_moderate, running_low, running_critical, moderate, complete and low_memory; iOS labels its warning ios_warning. One figure for the whole picked range.
Better: Lower is better. Beside the figure, its change from the prior range of the same length: green when it moved the better way, red when it moved the other way.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on memory_pressure.event.

Median battery level

The median battery-level report: half read more charge than this. Low means your app must be frugal.

How it is computed: The median of dartastic.battery.level, shown as a percent. One figure for the whole picked range.
Better: Higher is better.
Colors: The figure turns amber below 50% and red below 20%.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on dartastic.battery.level.

The share of battery reports with iOS Low Power Mode or Android Battery Saver on; a device that reports more often weighs more.

How it is computed: The average of dartastic.battery.low_power_mode, shown as a percent. One figure for the whole picked range.
Better: Lower is better.
Colors: The figure turns amber above 20% and red above 50%.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on dartastic.battery.low_power_mode.

Devices reporting each battery state

How many devices reported each battery state. Each device counts once, under the state it was in at the end of the step. More unplugged means more battery-impact pressure on your app.

How it is computed: The sum of dartastic.battery.state, one line per state. The SDK keeps it at 1 for the state a device is in and 0 for the state it left. Lines, one point per step across the picked range.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on dartastic.battery.state.

Thermal state

Thermal state by platform

The worst state any device reported, each step: 0 nominal, 1 fair, 2 serious, 3 critical, 4 emergency. Android's thermal status maps onto the same scale. Sustained 2 (serious, the OS is throttling you) and up means the app is too hot for the device.

How it is computed: The highest value of dartastic.thermal.state, one line per os.type. Lines, one point per step across the picked range.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on dartastic.thermal.state.

Thermal state changes, total

Thermal state changes on every platform. A handful a day is normal; dozens an hour means the app is fighting the device.

How it is computed: dartastic.thermal.state.event, every platform. One figure for the whole picked range.
Better: Lower is better. Beside the figure, its change from the prior range of the same length: green when it moved the better way, red when it moved the other way.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on dartastic.thermal.state.event.

Devices reaching serious thermal state or worse

Distinct app installs that reported serious, critical or emergency. Single digits are isolated devices.

How it is computed: Distinct app.installation.id values on dartastic.thermal.state.event where dartastic.thermal.state is serious, critical or emergency, every platform. One figure for the whole picked range.
Better: Lower is better.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on dartastic.thermal.state.event.

Application exit reasons

App exits by reason

Exits from Android ApplicationExitInfo and iOS MetricKit, by reason. Normal is a user closing the app; the rest are yours to explain.

How it is computed: dartastic.app.exit.count, counted per app.exit.reason. Slices of one whole, each figure for the whole picked range.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on dartastic.app.exit.count.

App exits per hour by reason

An exit counts at the app's next start, not when it ended; on iOS, at MetricKit's delivery, usually a day later. A rise with a build's adoption is a regression in it.

How it is computed: The per-hour rate of dartastic.app.exit.count, one line per app.exit.reason. Lines, one point per step across the picked range.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on dartastic.app.exit.count.

Low-memory exits

Exits the OS made for lack of memory: iOS out-of-memory and memory-pressure terminations, and Android low-memory kills.

How it is computed: dartastic.app.exit.count where app.exit.reason is oom or memory_pressure. One figure for the whole picked range.
Better: Lower is better. Beside the figure, its change from the prior range of the same length: green when it moved the better way, red when it moved the other way.
Colors: The figure turns amber above 1 and red above 10.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on dartastic.app.exit.count.

ANR-killed exits

The system killed the app for unresponsiveness. The in-app ANR detector catches these before the kill.

How it is computed: dartastic.app.exit.count where app.exit.reason is anr. One figure for the whole picked range.
Better: Lower is better. Beside the figure, its change from the prior range of the same length: green when it moved the better way, red when it moved the other way.
Colors: The figure turns amber above 1 and red above 5.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on dartastic.app.exit.count.

Exits with a stack trace

Exits where Android carried a tombstone or MetricKit a call stack tree: the ones you can act on.

How it is computed: dartastic.app.exit.trace.available. One figure for the whole picked range.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on dartastic.app.exit.trace.available.

Median memory at exit

The resident set size when Android ended the app, the median across exits. Trending up over a release is a leak.

How it is computed: The median of dartastic.app.exit.memory.rss. One figure for the whole picked range.
Better: Lower is better.
Filters: Build, Platform and Service narrow it.
Opens: its title opens the Metric screen on dartastic.app.exit.memory.rss.

App exits by reason and build

Exits by reason for every build, whatever the Build filter, stacked. A reason spiking for one build only is a shipped regression.

How it is computed: dartastic.app.exit.count, one stacked segment per build and app.exit.reason. Stacked bars, one per step across the picked range.
Filters: Platform and Service narrow it; Build does not.
Opens: its title opens the Metric screen on dartastic.app.exit.count.