Crashes
Crashes in the Diagnose area (Issues) — route /diagnose/crashes.
Crashes lives in the Diagnose area of the dashboard, under Issues.
At a glance#
| Dashboard route | /diagnose/crashes |
| Area | Diagnose (diagnose) |
| Group | Issues |
| Platforms | Mobile apps only (iOS, Android, React Native, Flutter). Hidden for web apps. |
What it does#
Crashes captures process-ending failures — native crashes on iOS and Android, and fatal JS errors — grouped by signature with the stack trace, device breakdown and affected releases.
When to use it#
Every release. Crash rate is the one quality metric where a regression is unambiguous, and release-over-release comparison is the fastest way to catch one.
Workflow#
Is it new, or a regression?
The issue record carries first-seen and last-seen. A crash that reappears after being resolved is a regression and deserves priority over a long-standing one.
Narrow by release and device class
A crash confined to one OS version or one device family is a different investigation from one spread across the board — and usually a much shorter one.
Read the stack, then watch the replay
The stack says where; the replay says how the user got there. Both are attached.
Limits#
Mobile only. Hidden for web apps, which have no equivalent process-death concept.
A crash during startup may arrive on the next launch. The report is written to disk and uploaded when the app next runs, so expect a delay rather than a loss.
nativeCrash()exists to test this pipeline. Guard it behind__DEV__— a call that survives into production is a crash you shipped deliberately.
Where the data comes from#
Release stack traces are unreadable without uploaded symbols.
From the SDK
Served by
Issues
Symbols
symbolication— internal module, no public endpoints