Issues
An issue is a group of events with the same stack trace. Issues are what you triage; the events underneath are the evidence.
How events become issues
Events are grouped by their stack trace — the frames from your own code, ignoring SDK and system frames. Events without a stack trace (messages) group by type and text.
Obfuscated and readable stacks look different, so an issue can be split in two until a symbol file arrives. CrashCart re-symbolicates recent events when you upload one and merges the issue. Upload mappings when you ship a release, not after the crashes come in.
Status
| Status | Meaning |
|---|---|
| Unresolved | New, nobody has looked at it |
| Triaged | Acknowledged, someone is on it |
| Resolved | Fixed. CrashCart remembers the release it was resolved on |
| Regression | Was resolved, then seen again on a different release |
| Ignored | Known, won't fix. Hidden from the default list |
A resolved issue that keeps crashing the same release stays resolved — old builds in the field aren't a regression. It becomes a regression only when it shows up on another release.
Change status on the issue page, in bulk from the list, or with the keyboard.
What an issue shows
- Title — error type and where in your code it happened, e.g.
NullPointerException at CartFragment.java:142 - Events — exact count, including events dropped by sampling
- Users — how many distinct users hit it
- First / last seen, and the release each happened on
- Stack trace of the latest event, symbolicated when possible
- Breakdown by release, device, OS version and environment
- Events — the individual occurrences, with breadcrumbs, tags and user
How long issues are kept
Raw events are deleted after RETENTION_DAYS (30 by default). The issue itself — its status, counts and history — is kept, so an old resolved issue can still be detected as a regression months later.