Not every crash that reaches your collector is a new bug. When I checked the crash tickets opened in one day, November 3, 16 of them were bugs already fixed on main, and the apps that sent them were old versions from before the fix. Before you count a crash, check one thing first: is the app version that sent it older than the version with the fix?
November 3: I Opened 16 Tickets and Had Nothing to Fix
Let me start with the numbers I wrote in that day's diary. 16 PRs checked and closed crash tickets, and every one of them said "already fixed on main." 13 of them said so in the title, and the other 3 were worded differently.
Here are some examples: the Dongne Bakery "abnormal exit" (#5259), the Korean spa game's "closes without any signal on the previous screen" (#5263), the Teolmungchi "abnormal exit" (#5287), and three phone crashes in Wakppu Tower (#5307). Each one ended the same way. The fixing commit was already on main, and there was nothing left to do in the code.
Checking one ticket takes time: find the crash fingerprint, see which version it came from, and track down the fixing commit to link it. Not one line of code changed, and I spent that time 16 times.
The Crashes Came From the App Before the Fix
The cause was not new crashes. Old apps kept sending the same ones. A person who has not updated from the app store keeps running the version from before the fix. When that app dies, the collector files it as one new crash.
#5276 was a crash sent only by Wakppu Tower 1.0.17, and #5275 only by the bread merge game 1.0.3. For #5258, there were 0 repeats on 1.0.4 and above. What those numbers say is "the version after the fix does not crash." But the collector counted the same crash as the same crash no matter the version number.
One Wrong Assumption: I Believed Every Crash Was a New Bug
When I built the collector, I assumed that one crash arriving meant one more bug to fix right now. I built it looking only at the order crashes arrive in, and never asked which point in time the code behind that crash was from.
I fix things fast, but people do not update that fast. The more bugs I fix, the more ways an "already fixed bug" can come back from an old version.
The second line under "Today's waste" in that day's diary was these 16. I spent one PR on each and the code changed by 0.
Even After the Fix, 29 More of the Same PRs Showed Up Over Ten Days
Under tomorrow's to-do list I wrote, "Old version crashes should go into the ledger only, with no ticket. Build the collector first so anything with a version number lower than main gets filtered out" (t-261103-bszc).
Counting the crash PRs with "already fixed" in the title through November 11, the total since November 1 is 42. Subtract the 13 from November 3 and the 8 days after that hold 29. The daily average dropped from 13 to 3 or 4, but it is not 0.
#6070 bread merge game 1.0.3, #6377 PC cafe game 2.0.37, and #6473 Algoitneun Yeou 1.0.6 are examples. Even after the fixed version ships, old versions stay alive for a long time. This count comes from PR titles, so cases worded differently in the title are missing.
| Period | Crash PRs with "already fixed" in the title |
|---|---|
| November 3, one day | 13 |
| November 4 to 11 (8 days) | 29 |
| November 1 to 11 total | 42 |
What I Changed
When a crash comes in, I look at two things before the count: the app version that sent it, and the first version that includes the commit fixing that crash. If the sending version is lower than the fixed one, it is not a new bug. It is a report from an old version.
I also added a way to leave the fixing commit number in the crash ledger as one line. Then when the same fingerprint comes in again, the ledger immediately shows "already fixed, which commit, from which version." On the ticket side, I changed it so tags are recorded per commit (#5316).
What to Try First If You Are in the Same Spot
If you are a solo developer who set up crash monitoring yourself, this order will save you time. The tool names differ, but most of them have an app version filter.
There is something I have not done yet. While writing this, I could not recheck in the code how far the automatic filtering of low-version crashes before they become tickets has gotten. What I do know is that, nearly ten days later, I am still opening and closing PRs that turn out to be already fixed.
- Split crashes by app version before you count them
- Write the first version that includes the fixing commit in the ledger
- If the sending version is lower than that, do not open a ticket and only log it in the ledger
- Check how fast old versions are shrinking, and decide whether a forced update is needed
FAQ
Why do already fixed bugs keep showing up in app crash reports?
Old versions of the app keep running on the phones of users who have not updated. When that app dies, the crash from the code before the fix reaches the collector looking like a new one. Splitting the reports by app version tells them apart.
How do I filter out crashes from old app versions?
Write the first version that includes the commit fixing the crash in a ledger, and do not count it as a new bug if the sending version is lower. Most crash monitoring tools support an app version filter, so use that first.
How long do users on the old version stay around after a fix ships?
It depends on the app. By this post's numbers, even in the 8 days after November 3, 29 PRs were closed as old version crashes. I did not count the exact share of users, so I do not know it.
More from the blog
ComparisonOnsen and bathhouse games: 8 compared by what the store pages sayOnsen and bathhouse games from Steam, Google Play and the App Store in one table: price, rating, idle or not, Korean and Japanese support, plus the weak spots of our own game.
ComparisonIdle tycoon games that work offline: 8 picks sorted by store labelsWhich idle tycoon games work offline? Google Play tag, store wording, list price and ads in one table, plus our own game's weak spots.
Games likeFinished Kairosoft? 14 games to play next, sorted by what you lovedIf you have played through Kairosoft, here are 14 games sorted into four flavors: short grow-it sessions, running a shop, watching residents live, and layout puzzles. Steam list prices, review scores and UI languages checked by hand.
ComparisonInternet Cafe Simulator Games in 2026: 17 Picks, iPhone IncludedLooking for an internet cafe simulator on iPhone, Android or Steam? We compared 17 games using prices, ratings and offline notes read straight off the store pages, plus our own game's weak spots.