Critical bugs in a mobile app: where things break
Critical bugs in a mobile app almost always live at the junctions, not in the middle of screens. Cold start is the most frequent failure scenario: the app crashes before the first screen renders, and the user has no idea what happened.
The second most frequent is session drop when returning from background: the access key has expired, silent renewal failed, and instead of the catalog the person sees an empty screen or a re-login form.
The costliest is a failure during payment. Payment goes to the gateway, confirmation doesn't reach the client, funds are debited — the order isn't placed.
This is not just a lost purchase: the user writes to support and demands a refund, and each such case is investigated manually and takes time from the team that could be working on the product.
A separate group is failures after a version update. The new build changes the local storage structure, the old data schema doesn't migrate, and the app crashes for those who installed the update on top of the previous version.
Alongside are sync failures after network loss: the accumulated queue of requests goes to the server out of order, and order statuses diverge.
The cost of such a failure is not only failed orders. The flow of support requests grows, the release has to be delayed, and rolling back the previous build through app stores won't be quick: publication and review take days. We break down how this is closed.
What a well-established failure triage changes: the effect in numbers
Metrics here describe not "it became more stable" but specific values: how much time passes from the first signal of a failure to the release of a fix, how widely the consequences spread, and how often the same failure returns.
Time to fix and detection window
A crash or freeze in a mobile app is tied to a specific device model, OS version, and part of the scenario.
While such failures are caught by app store reviews, the detection window stretches to days, and by the time it's confirmed, the failure affects a noticeable share of active users.
Automatic crash collection — Crashlytics and similar platforms — shortens this window to hours: the signal arrives tied to the build, device, and user action chain.
Then prioritization comes into play: first we fix what blocks login, payment, and checkout; the rest goes into the planned release. Reproduction in a test environment takes hours, not days, so time to fix stops being measured in weeks.
The class of failures that previously surfaced only for part of the audience is filtered out by pre-release checks.
Share of repeat reports for the same failure
A repeat failure is a sign that the cause was muted, not eliminated. In triage, we identify the root cause and close it with a check: the scenario that led to the crash goes into an automated test suite, and an alert is set for the same crash signature.
In measurements of real reports, the share of repeat reports for the same failure drops noticeably, and release stability becomes a measurable value: every fix is accompanied by a check that adjacent scenarios haven't broken.
Response formats for critical bugs: on-call, fix window
A critical bug in prod isn't resolved by asking "is there a free developer" — the response mode is chosen in advance. There are two working modes, and they complement each other: constant on-call with an alert channel and a fix window with rollback rules.
On-call and alert channel
The on-call engineer receives a signal from the monitoring system and confirms it before users write about the crash.
Rotation and the escalation ladder establish who the signal goes to if the first on-call engineer is silent: a general chat won't do; there the message drowns in conversation.
Fix window and rollback rules
An urgent fix goes outside the usual release process, but not instead of it: the rollback rule is agreed before work begins, not at the moment the build is already ready.
If the cause isn't found within the window, we return to the previous release and continue triage without pressure.
| Option | When it fits | Limitations |
|---|---|---|
| Constant on-call with escalation | Payments, authorization, order flow — downtime is immediately noticeable | Requires rotation and an alert ladder, higher organizational load |
| Scheduled on-call | The load is concentrated during working hours | Night and weekends remain without immediate response |
| Fix window with rollback to the previous release | The incident affects data or payments | Data schema backward compatibility is required |
| Planned release per process | Copy, cosmetics, non-critical failures | A critical bug waits for the nearest release |
How we handle a fix: from signal to verification
A critical failure in production brings lost sessions and support requests every hour, so we run the fix as a pipeline with fixed checkpoints. The workflow is the same for any signal — from intake to handover to maintenance.
- Intake and classification. We consolidate crash reports, analytics, and support requests into a single stream and calculate the share of affected sessions — it sets the priority.
- Signal triage. We correlate the failure with the build version, device model, and OS version, and reconstruct the call stack.
- Failure reproduction. On a test bench and a device fleet, we bring the scenario to stable repetition — without this, the fix turns into guesswork.
- Fix and regression. A minimal change in the affected path plus checks around it: adjacent scenarios must not break.
- Verification in production. We release in waves, and at each one we monitor the failure rate.
- Handover to maintenance. We record the cause, fix, and checks in the process so the next similar signal is triaged faster.
How signal triage is structured
Identical crashes arrive in dozens of reports, so they are collapsed into unique failures and sorted by the share of affected sessions. Separately, they check whether the failure reproduces on a specific device model — this filters out environment noise.
The call stack is reconstructed from build symbols: without this, the report remains a set of addresses.
Verification on real users
A fix is ready not after tests, but after confirmation on live traffic. Rollout goes in waves — first a small share of the audience, then the rest, with automatic return to the previous build if the failure rate exceeds the threshold.
Processes, diagrams, and observation points that remain with you
The work ends not with a report, but with a set of artifacts your team can use to triage an incident and release a fix on its own. Everything we set up in the process is handed over in working form — with filled-in fields, not "for the future" templates.
Composition of the handover materials
- Fix process: criticality levels, response time for each, who decides on an urgent release and who confirms rollback.
- Alerting scheme: on-call channel, escalation procedure, at what point the department lead is brought in.
- Access and role matrix: separation by repository, build pipeline, release storage, and monitoring panel — with owners indicated.
- Incident documentation: a triage template where the cause, detection time, and time to fix are recorded, and a log of already triaged cases.
- Observation points: a set of signals and thresholds by which a failure is visible before complaints — crash rate, freezes on startup, error growth after a new version is published.
- Rollback map: which builds remain available in stores and registries, how to return the previous version, and what happens to local data in that case.
- Reproduction instructions: how to capture logs from a device, which test benches and accounts are needed for this.
How to maintain the process without us
The process lives as long as it is reviewed. We compare signal thresholds with the real flow of reports once a quarter: some metrics become outdated after an OS version change or third-party module update.
After each major incident, the triage template is expanded with new fields — this is how a base of typical causes accumulates, and the next similar failure is closed faster.
The on-call engineer should be walked through the alerting scheme on a training scenario: we simulate a crash and see whether the stated response time was met.
Incident triage: time to fix before and after
After the release, the app crashed on payment confirmation: first for individual users, a day later for every fifth one. Crash signals in Firebase Crashlytics were growing, but they weren't tied to a specific user action, and releasing a fix took days. We broke down a case where the failure was closed not by a one-off fix but by a process change.
What it was before and what it became
| Metric | Before | After |
|---|---|---|
| Time from first signal to fix in release | 4–6 days | 6–10 hours |
| Share of repeat failures of the same class | 38% | 4% |
| Failures closed before the user reports | 1 out of 10 | 7 out of 10 |
More significant than the speed of one engineer was the eliminated class of failures: crashes stopped returning in subsequent releases because the cause was recorded as a reproducible case, not as a point patch.
What we did differently
Each release got a label by which crash reports are separated by version rather than mixed into one stream. We added automatic context collection: screen, scenario step, session state — this was enough to reproduce the failure without back-and-forth with support.
We set up a rule for automatic rollback to the previous version when crashes spike in the first hours after rollout and introduced a mandatory verification scenario for each closed incident. Time to fix decreased, and the share of repeat failures fell by almost ten times.
How an urgent fix differs from a planned release
An urgent release is a change with a minimal diff from the tag of the last stable release: only the fix for the cause of the failure goes into the build, everything else remains as before.
The path to the device is shortened to hours, but only the affected scenario is checked, without a full automated test run.
Hence the limitation: an urgent release is justified when the failure takes down a key path — startup, authorization, payment — or affects a noticeable share of devices.
A planned release accumulates fixes and goes through full regression. It is predictable and doesn't leave unverified areas, but the cycle takes days, or even weeks: everything noticed waits for the next rollout window.
If the defect doesn't block the user, treating it here is cheaper — fewer manual checks and lower risk that one fix pulls in a second.
Rolling back a version doesn't cure the defect but returns the app to the last known working state. It is limited by two conditions: the previous build is indeed stable, and the server side hasn't changed the data exchange format so much that the old client can't talk to it. If the data schema has already migrated, rollback turns one failure into two.
Choosing the mode is choosing the risk class, not speed. We look at three signs: does a key scenario break, is there a workaround, and does the previous version remain compatible with the server side.
These answers show whether an urgent release is needed, waiting for a planned release, or an immediate rollback.
Access, timelines, and repeatability: common concerns
Concerns at the start rarely relate to technology — more often it's organization: how quickly access will be granted, what to do about a floating failure, who is available outside working hours. Below are the things we discuss before signing the work plan.
What access to production is needed and how quickly is it granted?
Minimal set — read access to the repository, build history, crash logs by release, monitoring metrics, and a test account. Read-only rights, granted through your access management system. If some sources are closed, triage is done on log copies and diagnostic timelines grow.
How long does onboarding into the project take?
The first day goes to building the picture: which releases are affected, on which devices the failure reproduces, what changed before the first case. Then — reproduction on a test bench or with a user group. We record the estimate and plan before starting fixes.
The failure is floating and is caught one time out of ten. What then?
We diagnose with telemetry: extended event collection in the build for a user group, a ring buffer of logs, session marking up to the crash.
If the cause isn't caught, we set protection against scenario repetition and continue monitoring — this closes the class of failures, not a single case.
How is on-call arranged and who is responsible for what?
We fix the incident response window, the on-call roster, and the escalation procedure. Our side is diagnostics, fix, and regression verification; yours is access, release windows, and build publication. We keep rollback to the previous version as a standard scenario, not an emergency one.
Let's discuss the task: what to send and how we'll start work
The more precise the input data, the faster we get to the cause of the critical failure and the estimate. Below is what helps start triage without a long back-and-forth: from these materials the engineer immediately sees the picture and names where to look for the bottleneck.
- Symptoms and frequency: on which OS versions and device models the app crashes, whether the failure reproduces consistently and in which scenario.
- Logs and crash reports for the period: call stack, session IDs, conditions under which the crash repeats.
- Access to the repository and build: the branch where development is done and the channel through which test builds are published.
- Release scheme: how often updates are released, who confirms publication in app stores.
- List of related services: server side, notifications, payment, analytics, maps.
- Constraints: data protection requirements, access process, windows when a fix may be released.
The order is simple from here. We discuss the task, match symptoms with logs, and come back with an estimate and plan: what we fix first, how we verify, and how we roll back if the fix isn't confirmed. After approval, work starts.
The cooperation format is a one-off critical failure triage or ongoing maintenance with on-call for emergencies.