21 March 2026
Crash-free is not the same as the bill paid
A session can be crash-free and still fail to record a bill payment. Stability and payment confirmation are different questions for a telecom customer app.
Stability reports are useful. They are also easy to over-read. A crash-free rate can look healthy in the same week that bill-pay success events collapse, because the payment WebView closed politely, the activity did not crash, and nothing told billing that money moved.
Two clocks
Crash reporters watch process death. Payment confirmation watches a billing acknowledgement. A WebView that returns a blank page is not a crash. A user who force-closes after thirty seconds of “processing” is not a crash. Both can leave commercial with an incomplete funnel and the customer with a deduction SMS and no in-app receipt.
What we put on the same page
In a measurement review we refuse to let a stability chart answer a payment question. We ask for the payment success definition, the receipt screen, and the SMS or email that billing already sends. Then we see whether the app event is allowed to fire before those exist. If it is, the crash-free story and the revenue story will keep drifting apart.
A modest request
If engineering can only add one check this month, add it on the receipt, not on the tap. The tap is easy to count and easy to celebrate. The receipt is the thing the subscriber will screenshot when they call.