App Crash Monitoring and Mobile Performance Tracking
App crash monitoring lets you see failures before users complain: which metrics to watch, which tools to use and how to prioritise what comes in.
rabbitclip teamPublished: 6 min read
Short answer
Crash monitoring for a mobile app is a setup that, whenever the app closes on a user's phone, automatically collects where the fault happened, on which device and in which version, and reports it to you. Performance monitoring measures the softer problems in the same way: launch time, stutter and memory use. With both in place you see the real health of the app in users' hands. Without them you decide from store reviews alone, and those reviews are the voice of only a small share of the people who hit the problem.
Someone whose app crashes usually does not write to you. They close it, try once more, then delete it. An app that runs fine on your test phones may behave differently on a three-year-old device or a weak connection. Monitoring is the only way to make that unseen group visible.
Are crash monitoring and performance monitoring the same thing?
No, they answer different questions. Crash monitoring captures the moment the app closes: on which line of code, on which device, on which system version and what the user was doing at the time. Performance monitoring measures what feels bad even when the app does not close: a slow screen, juddering scroll, swelling memory.
On Android there is a third kind of fault, the application not responding, known as an ANR. The app does not crash but freezes, and the system offers the user a chance to close it. A good monitoring setup shows these three groups, crashes, unresponsiveness and slowness, separately.
Which metrics should you watch?
A few meaningful indicators are better than a wall of charts. The first is the crash-free session rate: the likelihood that a session ends without a fault once the user opens the app. Compare it across versions; if it falls in the new release, the release has introduced a regression.
The second group is performance indicators. The store dashboards also offer their own health figures. Google Play Console and Apple's developer tools show crash and unresponsiveness data collected from users at no charge, and for most businesses that is the place to start.
- Crash-free session rate, compared version by version
- Cold start time: how quickly the app opens when fully closed
- Slow and frozen frame rates: how smooth scrolling and transitions feel
- Unresponsiveness (ANR) events and the device models affected
Which tools and data should you collect?
There are ready-made services widely used for crash reporting; Firebase Crashlytics and Sentry are well-known examples. The choice depends on the infrastructure the team already uses and on what you need to monitor. More than the name of the tool, it is the correctness of the setup that makes the difference.
The part of the setup most often skipped is making the report readable. The code in a released app is obfuscated and stripped of names, so to make a crash report legible you must upload the matching symbol and mapping files to the monitoring service with every release. If you do not, the report is a list of meaningless addresses and nobody can tell where the fault lies.
Reports also carry context: the user's last few steps, the version number, the device model, the network state. Be careful that this context holds no personal data; names, email addresses and card details should never enter a report. How personal data ends up in logs is worth discussing with a lawyer or a data protection officer.
How do you prioritise the faults that come in?
Once monitoring is running, the first week produces a list of dozens of faults, and chasing all of them is impossible. Priority rests on two tests: how many users are affected and at what point in their journey it happens. A single crash during payment, sign-in or registration comes before a common but harmless one on the settings screen.
A fault that appears with a new release is treated separately, because it is a regression and usually the quickest kind to fix. Where possible, rolling a new version out to users in stages lets you halt the release when a problem shows up.
- Number of users affected and how often it repeats
- The moment it occurs: payment, sign-in and registration first
- Whether it began with the new release, in other words whether it is a regression
- The device and system version group affected
What mistakes are common in crash and performance monitoring?
The commonest mistake is setting up monitoring after launch, so the first wave of crashes passes unseen. The second is collecting reports that nobody reads. One person or role should review the faults regularly and watch closely in the first days after each release.
The third is testing only on the newest phones. The real user base includes older devices and slow connections, and that is where performance problems tend to show.
- Setting up monitoring after launch
- Not uploading symbol and mapping files, leaving reports unreadable
- Collecting reports with nobody reviewing them regularly
- Writing personal data into reports or logs
When is performance monitoring unnecessary or premature?
For an app that has not launched and has no users, a detailed performance dashboard is premature; there is no data to interpret. At that stage, setting up crash reporting is enough, since from the first real users it gives you a safeguard that is close to free and needs little upkeep.
A complex monitoring stack is also needless for a simple corporate app with few users that is rarely opened; the free health data in the store dashboards may be enough. The test is this: if monitoring does not change a decision you would make, it is surplus.
Crash and performance monitoring is how you see the app as users really experience it, while store reviews show only the loudest part of the problem. Set monitoring up before launch, upload the files that keep reports readable with every release, review a few meaningful metrics regularly and rank faults by how many users they affect. If you would like help working out how to monitor the health of your app, you are welcome to arrange a discovery conversation with rabbitclip.
FAQ
What is the crash-free session rate?
It is the share of sessions that run from app launch to close without a crash. Compared across versions, it gives a quick read on the stability of a new release.
Should I use a ready-made tool for crash monitoring?
For most businesses, yes. Widely used services such as Firebase Crashlytics and Sentry offer a ready solution, and building your own rarely adds value. The real difference lies in setting it up correctly and uploading the symbol files.
Are the store dashboards enough on their own?
They are often enough to start with, since they show crash and unresponsiveness data at no charge. To see where and at which step a fault occurs, and to compare across versions, a separate monitoring tool is usually needed.
Does monitoring data count as personal data?
It can, if a report includes information that identifies the user. Take care not to add names, email addresses or payment details to reports, and ask a lawyer about your app's legal position.
