Every crash and error your SDKs report, grouped into issues. Crash-free rates by profile and session, stability per release, and a full trail for each group, from the stacktrace to the sessions that led there.
What a crash group is
When your app crashes, the SDK sends a report. Every report becomes an event in your project's data, and the server files it into a crash group, one group per distinct error. The Issues list shows groups; a group's page shows everything gathered about that one error, including each individual report.
Grouping works on a cleaned version of the error. By default the seed is the error's name plus its top stack frame, so the same bug reported from slightly different call sites still lands in one group. Smart preprocessing strips the volatile parts first, such as ids, memory addresses, file paths, and timestamps, so two reports differing only in a pointer value do not become two groups. Both behaviors are configurable, see Grouping strategy and Smart preprocessing.
A report is either fatal, the app terminated, or non-fatal, a caught error the app survived. Both are collected; the fatal flag is a pill on the group and a count on the Issues tab.
A group carries a lifecycle. It is new until someone opens it, then open. Marking it resolved records the version it was fixed in. If it crashes again on a newer version it comes back as regressed. Ignoring hides it from default views without deleting anything.
How stability is measured
The two headline numbers are crash-free rates. Crash-free profiles is the share of profiles that hit no crash in the period. Crash-free sessions is the share of sessions in which no crash occurred. Sessions supply the denominators, which is why a project that stops sending sessions also loses its crash-free rates.
The Overview cards read these numbers for the latest app version only, and say so in the strip above them. That is deliberate. Your current release is the one you can still fix, and a healthy latest version can hide behind a good all-time average. The crash rate by version table below the cards has every version, so nothing is lost.
Crashes per 1k sessions is the comparable rate the version table uses. It divides a version's occurrences by that version's sessions, so a busy release and a quiet one can be compared fairly.
Use Cases
Triage after a release
The morning after a rollout, the question is what broke and how badly.
- Open the Issues tab and set the version filter to the new release. Add a platform if the rollout was staged.
- Sort by occurrences. The top rows are the volume; the fatal count in the strip tells you how much of it terminated the app.
- Watch for the regressed status. A fixed bug that returned on this release is usually the fastest thing to act on, the fix exists and stopped working.
- Open the worst group, read the stack, and decide. Resolve it when a fix ships, or ignore it if it is noise such as a third party SDK error you cannot act on.
Judge whether a release is stable
Whether a release improved stability is a comparison, not a single number.
- On the Overview tab, find the release in the crash rate by version table. The rate is crashes per 1k sessions, so versions with different audiences compare fairly.
- Read the vs previous column. It compares each version's rate to the one before it, which is the question a release actually asks.
- Click the version to jump to the Issues list already filtered to it, and see which groups produce the rate.
- On the Trends tab, the crash-free rate by version chart shows the same story over time, useful when a release degrades days after rollout rather than on day one.
Get to the bottom of one crash
A crash group's page is built to answer where, who, and why.
- Open the group from the Issues list. The header pills tell you its status and whether it is fatal at a glance; the metric strip sizes the problem.
- Read the stacktrace. In-app frames are highlighted, and symbolicated stacks show your own symbols when symbols are uploaded.
- Check device metrics and state. A crash that only happens with low memory, or only in the background, usually says so here.
- Read paths to the crash. These are the event sequences profiles most often walked right before crashing, computed backward from the crash, and they often name the screen or action that sets the bug up.
- Open an occurrence from the table at the bottom for one concrete report, with its own stack, device facts, and the profile behind it.
Make stacktraces readable
Native and minified stacks arrive as addresses and mangled names. Symbolication maps them back to your source using the symbol files you upload.
- Upload symbol files for each build in Manage, under Data, or from the crash page's binary images link, which lists the exact modules loaded at crash time.
- On a crash page, use the symbolicate action. When the group is symbolicated, a switch appears to flip between the symbolicated and the original stack.
- Occurrence stacks in the investigation panel symbolicate the same way, so a single odd report can be read in source terms too.
Symbolication needs the symbols of the exact build that crashed. If a version's symbols were never uploaded, its groups stay unsymbolicated until they are.
FAQs
What is the difference between fatal and non-fatal?
Fatal means the app terminated. Non-fatal reports are exceptions your code caught and reported deliberately; they count toward occurrences but signal a survived error.
Why did a resolved crash come back as regressed?
It occurred again on an app version newer than the one it was resolved in. The same crash on an older version does not regress the group.
The stack on the group page does not match my newest report. Why?
The group shows the stack from its newest report on a newer app version. Same-version reports do not replace it unless the server is configured to allow that.
Why do Overview numbers disagree with the Issues counts?
The Overview headline cards are scoped to the latest app version, while Issues counts follow your current filters. Clear the filters and compare per version to reconcile them.
Can one profile produce many occurrences?
Yes. Occurrences count reports, affected profiles counts distinct profiles, which is why the two differ.
Do crashed sessions still count as sessions?
Yes. A crashed session is a session; it just is not crash-free.