Firebase Crashlytics is most useful when a crash report becomes a reproducible engineering task rather than an isolated alert. This guide presents a repeatable triage workflow for grouping issues, validating severity, enriching reports with breadcrumbs and custom keys, checking release and symbolication data, detecting regressions, and moving fixes through verification. Use it during weekly crash reviews, after major releases, and whenever crash patterns change unexpectedly.
Overview
Crashlytics helps mobile teams observe crashes and non-fatal errors in the context of affected app versions, devices, operating systems, and user activity. The console can show the scale and recurrence of an issue, but the report alone rarely explains the complete cause. Effective Firebase crash reporting therefore combines Crashlytics data with release history, application logs, reproduction steps, source control, and product impact.
A reliable triage process answers five questions:
- What is failing, and how consistently can the failure be identified?
- Which users, app versions, platforms, or workflows are affected?
- Is the issue new, recurring, worsening, or already resolved?
- Can the team reproduce it with the available context?
- What change will fix it, and how will the team verify the fix?
Start by confirming that the relevant Crashlytics SDK is integrated correctly for each supported platform and that release builds provide the symbol or mapping information required for readable stack traces. Terminology, SDK behavior, and platform reporting requirements can change, so verify implementation details against the current Firebase documentation when upgrading a mobile framework, operating system, or Crashlytics integration.
What to track
Issue identity and grouping
Use the Crashlytics issue as the primary unit of triage, but do not assume that one issue always represents one root cause. Grouping is useful for reducing duplicate noise, while similar stack traces can still hide different triggers. Record the issue title or signature, first observed release, latest affected release, platform, and whether the issue is open, resolved, or appearing again after resolution.
When comparing reports, look for a shared failing function, exception type, code path, or user action. If two reports have the same top frame but different inputs or workflows, separate them in the investigation notes rather than forcing them into one explanation.
Severity signals
Prioritize more than the raw event count. Track affected users, occurrence frequency, app version, business-critical workflow, user-visible impact, and whether the app can recover. A crash during launch or account access may deserve immediate attention even when it occurs less often than a minor failure in an infrequently used feature.
| Priority | Typical signal | Recommended response |
|---|---|---|
| P0 | Launch failure, data-loss risk, broad production impact, or a critical workflow blocked | Assign an owner immediately, establish a reproduction path, and consider mitigation or rollback options. |
| P1 | High recurrence, meaningful user impact, or a regression in a recent release | Schedule an urgent fix and monitor the affected release while the investigation proceeds. |
| P2 | Limited audience, reliable workaround, or moderate product impact | Place in the normal engineering queue with a defined owner and target release. |
| P3 | Rare event, low impact, or insufficient evidence of a current user problem | Collect more context, review periodically, and avoid allowing the issue to disappear without a decision. |
This table is a starting policy, not a replacement for product judgment. Record the reason for the priority so it can be reassessed when affected users, release versions, or reproduction evidence change.
Context that makes reports actionable
Use Crashlytics custom keys for bounded, non-sensitive state that helps explain the execution path. Examples include a screen name, feature flag state, checkout step, sync state, or API operation category. Prefer stable values such as checkout_review over unrestricted user-generated text. Do not place passwords, authentication tokens, payment details, private message content, or other sensitive data in keys, logs, or breadcrumbs.
Breadcrumbs can show the sequence of navigation or user actions leading to a failure. Add them at meaningful boundaries—such as entering a screen, starting a sync, receiving a deep link, or changing an important state—not on every low-level event. Excessive logging makes reports harder to read and can increase privacy and storage concerns.
Track non-fatal errors separately from crashes. A non-fatal event may indicate a degraded feature, failed network operation, parsing problem, or recovery path that users experience without an app termination. Review its frequency, affected versions, and relationship to crashes; it may be an early signal of a broader reliability problem.
Release and symbolication data
Every report should be connected to a recognizable release or build identifier. Without consistent version labeling, teams can mistake an old issue for a current regression or fail to confirm that a fix reached production. Keep release identifiers aligned with the build process and make the mapping from an app build to a source-control commit easy to retrieve.
Unreadable stack traces slow investigation. Check that symbol files, debug information, or platform-specific mapping files are uploaded as part of the release workflow where required. If a report is not symbolicated, treat that as a release-process defect and correct the pipeline rather than relying on guesswork.
Cadence and checkpoints
During each release
- Confirm the build has the intended Crashlytics configuration and release identifier.
- Verify symbolication or mapping-file upload for the target platform.
- Test a controlled crash or non-fatal path in an appropriate development or test environment, following the current SDK guidance.
- Confirm that sensitive values are excluded from custom keys, logs, and breadcrumbs.
- Record the commit, build, release channel, and notable feature flags.
Weekly crash review
Review new, worsening, and recurring issues rather than scanning every report equally. For each candidate, compare the current release with the previous release, identify affected device or OS segments, inspect the stack trace and context, and assign one owner. Close the meeting with a decision: fix now, investigate further, monitor, or accept temporarily with a documented reason.
Monthly or quarterly quality checkpoint
Look for patterns across releases. Are the same modules producing repeated failures? Are non-fatal errors rising before crashes? Are reports consistently missing symbols or useful context? Does the priority policy still reflect the app’s most important user journeys? A scheduled review turns Crashlytics from a reactive inbox into a feedback loop for release quality.
How to interpret changes
A sudden increase after a release is a strong reason to compare the changed code paths, configuration, dependencies, feature flags, and affected platform segments. It is not proof that the latest release caused every event. Check whether the apparent increase reflects a larger rollout, improved reporting, a new grouping pattern, or a change in user behavior.
A stable event count can still conceal a serious problem if the number of affected users is growing or if the issue is concentrated in a critical workflow. Conversely, a high event count from a small number of repeatedly failing sessions may require a different response from a broad, low-frequency failure. Compare events with affected users and product context.
When an issue is marked resolved, verify the next relevant release rather than treating resolution as proof of a fix. A regression is especially important when the same issue returns after a release that was expected to address it. Capture the old and new release identifiers, the suspected change, reproduction conditions, and the evidence that distinguishes recurrence from a newly grouped issue.
Investigation checklist
- Copy the issue identifier, signature, priority, and current status into the team tracker.
- Record affected users, event volume, first and latest occurrence, and affected releases.
- Inspect the complete stack trace and confirm whether it is symbolicated.
- Compare device, OS, app version, feature flag, screen, and workflow context.
- Review breadcrumbs, custom keys, and related non-fatal events for a sequence.
- Check recent commits, dependency updates, configuration changes, and rollout stages.
- Reproduce with the same release and a representative device or emulator where possible.
- Assign an owner, define the proposed fix, and state the verification evidence required.
Incident-to-release template
Issue: [Crashlytics issue and signature]
Impact: [affected users, workflow, and release scope]
Priority and owner: [priority, engineer, and reviewer]
Evidence: [stack trace, breadcrumbs, keys, logs, and reproduction steps]
Suspected cause: [code path, configuration, dependency, or unknown]
Fix: [commit, pull request, feature flag, or mitigation]
Verification: [test case, build identifier, rollout observation, and Crashlytics comparison]
Follow-up: [monitoring date, regression check, and documentation update]
When to revisit
Revisit this Crashlytics triage process after every major SDK, framework, mobile operating system, or release-pipeline change. Also review it when Crashlytics console terminology, supported reporting behavior, symbolication requirements, or privacy expectations change. The operational policy should be checked at least monthly during active development and at a quarterly quality review for more stable products.
Make the next review practical: export or record the current top issues, compare them with the prior review, identify unresolved regressions, and select one instrumentation improvement if reports lack context. Before the next major release, run the release checklist, confirm symbolication, test the reporting path, and verify that owners can move from a report to a reproducible case. Pairing this workflow with a broader Firebase production deployment checklist and a repeatable Firebase CI/CD workflow helps reliability checks remain part of delivery rather than an afterthought.
