Crash budgets for mobile apps

Teams often measure crashes, but still ship through spikes because there is no decision rule. The dashboard says “bad”, yet release pressure wins and the spike becomes “tomorrow’s problem”. Crash budgets turn “quality” into a clear release gate with an explicit yes/no outcome.

Start with two numbers: crash-free sessions and startup time. Define the threshold that blocks rollout and the escalation path for exceptions. If exceptions exist, they must be intentional: who approves them, what rollback plan exists, and what additional monitoring is required.

Paired with phased releases and feature flags, this keeps cadence high without grinding trust down. It also builds credibility: stakeholders learn that releases won’t silently degrade the app, and engineering can negotiate scope with data instead of opinions.

Pick one metric that reflects user pain (crash-free sessions) and one that reflects experience (startup time). Use both: crashes catch correctness issues, startup time catches performance regressions. Make the metrics cohort-aware (by OS version, device class, region) so you don’t miss issues that only affect a slice of users.

Define an escalation rule: who can override the gate, under which conditions, and what compensating controls apply (smaller rollout, extra monitoring, faster rollback). The rule should be written down and rehearsed, so it’s calm during a real incident instead of invented on the spot.

Crash budgets aren’t about perfection — they’re about preventing quality debt from silently accumulating. If you ignore regressions repeatedly, you train the organization to accept brokenness; budgets reset expectations and keep “ship now, fix later” from becoming the default culture.