When your app crashes on a customer, they almost never tell you.
They do not ring, they do not email, and they very rarely leave a review. They try again once, it does the same thing, and they put the phone down and use something else. The app stays on their home screen for a few weeks and then it doesn't.
Which means the ordinary signals a business runs on are all missing. No complaint, no ticket, no angry call. The first thing most owners actually see is usage drifting down over a couple of months, or a one star review six weeks later saying "kept crashing, deleted it". By then the people it happened to are gone, and you have no way of knowing how many there were.
Support tickets are the tail end, not the picture
It is tempting to reason from the complaints you did get. If two people reported a problem, it feels like a two person problem.
It is not. The people who take the trouble to report a fault are a small and unrepresentative slice: they are usually your most engaged customers, on the most common phone, doing the most common thing. The customer on an older Android handset who cannot get past your sign up screen will never appear in that list, because they never became a customer in the first place.
So the number of complaints tells you almost nothing about the size of the problem. It mostly tells you how patient your best customers are.
The app can just tell you itself
Crash reporting is a small piece of code inside the app that notices when something has gone wrong and reports it back automatically, from real customers' phones, with no action from them at all. It has been standard practice for years and it costs nothing to run at the volumes an SME app operates at.
The tool we use for this is Firebase Crashlytics, and the reason we push its data into a proper database afterwards is that the console on its own answers "what is broken" but is poor at answering the questions an owner actually has. Those are business questions, and they need querying rather than browsing.
There are four worth asking, and the order matters.
1. How many people, not how many crashes
This is the number that gets reported wrongly more than any other, and the two are wildly different.
Thirty seven crashes sounds like a serious incident. It might be one person on a train tunnel commute, opening the app and having it fail thirty seven times in twenty minutes, and it might be thirty seven separate customers who each hit it once and gave up. Those are completely different situations. The first is an annoying bug affecting one determined user. The second is thirty seven lost customers.
Insist on being shown affected people alongside the event count, every time. If a report only gives you one of those numbers, it is the less useful one.
2. Did it start at the last release?
Every crash report carries the app version it happened on. That turns a vague "the app is buggy" into something you can act on within a day.
If a problem appears only on the version released last Tuesday, you have caused it, you know roughly where, and it can be fixed and shipped quickly. If it has been running at a steady low level across six versions, it is a long standing edge case and it competes with everything else for attention rather than jumping the queue.
This is also the check that should happen automatically after every release, because the window where a bad release is cheap to fix is short.
3. Which phones, and which version of the operating system?
A crash that happens on every device is a straightforward defect and it will be found quickly. The ones that quietly cost you money are the ones concentrated somewhere specific: one manufacturer, one screen size, one older version of Android or iOS.
Those are exactly the crashes that never reproduce on the developer's phone, never reproduce on yours, and get closed as "cannot replicate" while continuing to happen to a real segment of your customers.
4. Are the affected customers the ones who spend?
This is the one almost nobody asks, and it is the one that decides what gets fixed first.
A crash on a screen that only new users see is a customer acquisition problem, and it is probably the most expensive bug you have, because you are paying to send people to a door that does not open. A crash in a rarely used settings screen, hitting people who have been with you for two years, is genuinely worth scheduling for next month.
Same number of crashes. Completely different priority. You cannot make that call from a list of error messages, which is why the data needs to be somewhere you can ask commercial questions of it.
The number to hold people to
If you want one figure to put in front of whoever builds your app, use the proportion of users who had no crash at all in a given period.
It is a good measure precisely because it counts people rather than events, so a single customer with a bad connection cannot make the month look like a disaster, and a rare crash affecting hundreds of people cannot hide inside a small total. It is also stable enough to set an expectation against and notice when it moves.
Ask for it monthly. If it drops after a release, you have your answer about that release.
What crash reporting will not tell you
Two honest limits, both of which matter.
Most of what ruins the experience is not a crash. This is the big one. The app that closes itself is obvious and gets fixed. The app that shows a blank screen, or a spinner that never stops, or silently fails to submit a booking, does not close and may not register as a crash at all. To a customer those are all the same event: your app did not work. If the only thing being monitored is crashes, you are watching the smaller half of the problem, and you should be asking whether errors that leave the app running are being captured too.
It tells you where, not why. A crash report will pin down the exact point the app gave up. It will not tell you what the customer was trying to do, or whether they had been fighting with the screen for five minutes beforehand. For that you still need to talk to people occasionally.
There is also a practical wrinkle worth knowing before someone promises you a dashboard for everything: some of the useful triage genuinely only exists in the crash reporting console, and cannot be pulled out into your own reports. The headline numbers export cleanly. Not everything does.
A quiet report is a real result
One last thing, because it surprises people. We look after apps where the honest answer for a given month is that nothing crashed at all, for anyone.
When that happens the instinct is to assume the monitoring is broken. Usually it is not: it is a small, well built app doing a specific job, and it simply works. Knowing that with confidence is worth having. It means the money you were about to spend on stability can go on something a customer will actually notice.
Where to start
If you have an app and you cannot answer "how many customers had a crash last month", start there. Crash reporting takes an afternoon to add and it works retrospectively from the moment it is switched on, so the sooner it is in, the sooner you have a baseline to compare releases against.
We do this as standard on the apps we build and maintain, including We-Fit and DooceyVision, with the crash data pushed into BigQuery so it can be queried properly rather than eyeballed in a console once a quarter.
If nobody has shown you these numbers for your own app, that is worth asking about. Get in touch and we will take a look, or read more about how we approach mobile development.