Crashlytics report is showing much less crashes than the actual amount. My App has over 20k active users and crashlytics reports only 18 crashes but 97.55% crash-free users.
Crashlytics Screenshot
I also implemented Flurry and it shows much more reasonable numbers, but the stack-trace is not as good as crashlytics.
Is there any way to get the correct number of crashes in crashlytics?
Related
We have an existing app that has Crashlytics implemented. As I understand, App Not Responding report in Crashlytics is only for Android 11 and above, which most of our traffic meets as a condition.
In Crashlytics, I can see % for crash free users, total users and total crashed but - for ANR metric. How can I implement this?
Thanks.
Last couple of weeks, I have been Observing difference between number of writes in Firebase console Firestore Usage tab and Google cloud console Quota page.
Before that, The count fairly used to sync.
Number of writes in Firebase Firestore console usage tab: 9.2K
Number of writes in Google Cloud Console page, Quotas Page: 19307
Which is approximately double the number of writes in Firebase Firestore Usage Tab. Are there any Internal writes happening which google doesn't report?
Firebase Console Firestore Usage Tab Page
Google cloud Console Quotas page
I have attached the screenshots for the same.
Can anyone clear My Query. Is this a valid Scenario?
Note: I Don't have any other project linked to the platform.
From your first screenshot you can see at the top left written on the graph “Does not include Imports/exports and may not match billing and quota usage”. Moreover, Google public documentation states that the Firebase console includes a usage dashboard that shows Cloud Firestore reads, writes, deletes and other metrics over time.
As a result of how the dashboard computes usage, the numbers reported can differ from billing reports. The billing reports are the final usage numbers.
The usage dashboard does not include reads and writes from managed import and export operations.
So,I have to answer my question.
I've found out the root cause. Firestore FieldValue atomic operations causing the double writes.
This double writes happening with any SDK version even in Cloud functions Admin SDK.
I've skipped the use of atomic operations using FieldValue. All Fine now.
Firebase Support Investigating the Issue. Will update When I Got more Info from them.
Edit:2
Response from Firebase support:
"The two writes come from: 1) the initial write and 2) the transformation. This is not a bug, and what is shown in the Cloud console is correct. We do have an internal ticket now to make sure the Firebase console syncs up this information better, as well, so hopefully that'll help."
That means Fieldvalue functions to increment and array Union, servertimestamp will cause two writes and I also found that they are causing extra reads as well. I feel Firebase should reconsider their decision of not considering it as bug or atleast restructure this Atomic Operation. Let's Wait and See.
I started using Firestore recently (Free plan) in my iOS app, the app is in Production now, and I see huge discrepancy in the number of Reads. App Engine Quota shows 1M reads of 0.05M (free quota) (Cloud Firestore Read Operations), while Firebase Console (Database tab) shows just a one hundred reads for today - 10,000 times difference!
The app can still read the data from the servers (it's not from cache as I tried to delete the app and reinstall), so the Firestore functionality is not limited by exceeding the free quota.
Each app user can read only one document (via listener) with applied security rules, and it reads own document only 3-5 times per session. There are about 50 users so far, so the expected number of reads matches Firebase console.
Is there a known bug in App Engine console?
Is there a way or free tool to understand the source of all those reads?
Which reporting tool is more reliable in general - Firebase Console or App Engine Console?
I appreciate your help guys!
The Crashlytics dashboard is showing Crash-free statistics but there is no crash in the ISSUES table.
Knowns:
Latest Fabric and Crashlytics following the Firebase tutorial
Forced a crash using Crashlytics.sharedInstance().crash()
In appdelegate I set FirebaseApp.configure()
App is not on Appstore, but I uploaded the dsyms from the xarchive package
That can happen from time and here's why - when a session ends in a crash, the small amount of data that needs to be sent to know that the crash occurred can safely be sent. However, the crash report is larger, so it can't be sent safely until your users relaunch the app. Once your users do that, the crash report will be sent and you'll be able to dive into the details. Let me know if that clears it up or if you have any other questions!
I've been using Crashlytics in application, our client using HockeyApp, and I came to know by the recent updates to Google Firebase.
Has anyone had a chance to use above tools, what are your overview and suggestion? Did you like one over the other... and why?
Have a great day.
I'm afraid I can't speak for HockeyApp at all, but I have some experience in using Firebase and Crashlytics using iOS and Android clients. The below paragraphs don't factor in HockeyApp, and only compare Firebase Crash Reporting to Crashlytics.
Of the two, I would depend on Crashlytics for crash reporting until Firebase can further revise features. I've implemented both in some apps, and there are some advantages to Crashlytics. They send email notifications when crashes occur, including for priority changes, and crashes appear very quickly in the interface, within 5 minutes typically.
As it currently stands, Firebase doesn't have crash notifications, and it can take 20-40 minutes for a crash report to appear in the dashboard. A benefit of using Firebase's reporting is that their analytics will create an audience group of crash experiencing users, allowing you to identify and provide a different experience for those users (push notification, welcome screen, coupon code, etc)
Both:
Ability to report logs for crashes to investigate interaction and
function
Crashlytics:
~5 minute reporting time
Email notifications
Firebase:
20-40 minute reporting time
Richer user data
Can redact some logged info: "Logged in Chris" could become "Logged in [REDACTED_US_MALE_NAME]"