Back to blog feed

Tutorials

Crash Triage Pipeline with Firebase + Structured Logs

How to combine Firebase Crashlytics and structured logs into one triage pipeline that cuts alert noise and prioritizes the crash that actually hurts users.

Crash Triage Pipeline with Firebase + Structured Logs

Most mobile teams do not have a crash shortage. They have a prioritization shortage. Crashlytics tells you what crashed; it does not always tell you what to fix first or how to reproduce quickly.

Why triage fails in growing apps

As DAU grows, a single release can produce hundreds of grouped issues. Without structured context, engineers chase noisy edge cases while high-impact failures continue.

The fix is to join crash signals with structured runtime context and route by business severity, not only stack trace count.

Unified crash event contract

We attached a structured log envelope to every fatal and near-fatal path:

Example crash context payload:

  • release: android-2.18.0
  • feature: checkout
  • tenant_tier: paid
  • network_state: cellular
  • user_journey_step: payment_submit
  • correlation_id: req-7f3d...

Crashlytics kept native grouping, while logs gave the context needed for impact scoring.

Enrichment pipeline design

Pipeline stages were simple and reliable:

  1. Crash occurs and is reported to Crashlytics.
  2. Matching structured logs are collected by correlation ID.
  3. A triage worker computes severity score.
  4. Ticket is created with owner, SLA, and reproduction hints.

Severity score combined:

  • Affected sessions
  • Paid-tenant impact
  • Crash recency
  • Feature criticality

This prevented low-value crashes from starving critical fixes.

Routing and ownership model

Each crash class mapped to an owner team and SLA band:

  • P0: payment/auth crashes for paid users -> immediate page
  • P1: high-frequency core flow crashes -> same-day fix
  • P2: edge-case crashes with workaround -> planned fix

Routing rules were codified, not discussed ad hoc in standups.

Dashboard that supports decision speed

The triage board showed only decisions engineers needed:

  • Top crashes by weighted impact score
  • Regression indicator vs previous release
  • Fix status and time-to-recovery
  • Verification status after hotfix rollout

No vanity charts. Only action metrics.

Verification loop after fix

Every crash fix required two confirmations:

  • Technical: stack trace signature no longer appears in canary cohort
  • Product: user journey recovery confirmed for affected flow

If either failed, ticket was reopened automatically.

Practical takeaway

Crash reduction is a system, not a dashboard. Combine Crashlytics with structured logs, score by impact, and automate assignment + verification. That is how triage stays useful when release velocity increases.

Related reading:

Comments

Threaded replies are enabled. Upvote useful ideas.