Which strategy should I use for Firebase Crashlytics Crash-Free Metrics Behavior?

Mobile teams need to know whether upgrading Crashlytics SDK versions will change crash-free user metrics and alert thresholds enough to require dashboard and SLO recalibration.

Upgrade to sessions-capable Crashlytics SDKs and reset your baseline, unless you need one more release cycle to preserve alert continuity and recalibrate SLOs.

Blockers

Who this is for

Candidates

Upgrade to sessions-capable Crashlytics SDKs and reset your baseline

As of 2026-03-27, Firebase documents a metric cutover for builds using sessions-capable Crashlytics SDKs: Apple v10.8.0+, Android v18.6.0+ with BoM v32.6.0+, Flutter v3.4.5+, and Unity v11.7.0+. For those builds, Crashlytics no longer uses Google Analytics to calculate crash-free users, and crash-free sessions becomes available. Release Monitoring also requires these same SDK minimums and uses session data for comparisons and active-user percentages. Firebase pricing lists Crashlytics as no-cost as of 2026-03-27, so the main impact is metric behavior and operational baselining rather than spend.

When to choose

Use this when you want the current Crashlytics feature set, including crash-free sessions and Release Monitoring, and you can tolerate a metrics discontinuity. Treat the first compatible production release as a new baseline, because Firebase states that a first release with a compatible SDK has no previous session data to compare against.

Tradeoffs

You get the most accurate current Crashlytics metrics and new dashboards, but historical continuity is weaker because the crash-free users calculation source changes and session-based metrics appear only on compatible builds.

Cautions

Do not compare pre-cutover and post-cutover crash-free metrics as if they were identical measures. If automatic Crashlytics data collection is disabled, Firebase says metrics quality is reduced. Release Monitoring also will not show a build until it has sufficient users in the last 3 days.

Sources

Hold older Crashlytics SDKs temporarily to preserve pre-cutover continuity

As of 2026-03-27, Firebase states that older Crashlytics SDK versions still rely on Google Analytics for crash-free users calculations, while newer sessions-capable SDKs do not. Holding on older versions can preserve continuity with the older crash-free users methodology for a short period while teams prepare dashboards, SLOs, and alert thresholds for the new metric behavior. The cost posture does not materially change because Firebase pricing lists Crashlytics as no-cost as of 2026-03-27. The downside is that older builds do not qualify for crash-free sessions or Release Monitoring's session-driven features.

When to choose

Use this only as a short migration bridge when metric continuity matters more than immediate access to new Crashlytics features. The decisive factor is whether your org needs one more release cycle to recalibrate alerting and stakeholder reporting before accepting the new baseline.

Tradeoffs

This minimizes short-term reporting churn, but it delays access to crash-free sessions, Release Monitoring comparisons, and Firebase's recommended metric path.

Cautions

Firebase strongly recommends updating to the latest Crashlytics SDK when an older version still depends on Google Analytics for crash-free users. This is a temporary risk-management choice, not a steady-state recommendation.

Sources

Facts updated: 2026-03-27
Published: 2026-04-03

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Which strategy should I use for Firebase Crashlytics Crash-Free Metrics Behavior?"
Missing something? Request coverage