32 results found
-
Crashlytics will report different stacks as different crash
Currently exception events are gathered as one issue depending solely on the actual exception location and its type.
Moreover, every such event pops all previous ones as regressed.
This makes it hard to follow the different issues. It is specifically a big problem where a fallback is used, with non-fatal crash reports in it. All crashes that ended up with the fallback are reported as one.
My suggestion is that different call stack and/or message will be shown as different issues. (Possibly with an option to set the differing place in the stack)1 vote -
Linear integration
When a crashlytics issue occurs, it creates a new issue in linear with a link to the crashlytics dashboard.
When a crashlytics issue is closed, close the associated issue in linear.
When a linear issue is closed, close the associated issue in crashlytics.
When a crashlytics issue receives velocity alerts, it increases issue priority in linear.1 vote -
Jira Cloud Integration for Post production issue type:
Currently, Crashlytics only supports Bug issue type with Jira Integration. It would be helpful if it allowed other issue types, such as post-production issues.
This solution allows users to integrate with their organization's Jira issue-type standards, including Pre-production, Post-production, and Defects, instead of relying solely on the issuetype "bug".
1 vote -
Custom quality control for "latest release"
Latest Release is a very useful functionality. For us, even when we have crashes that are worth hot-fixing, it shows as successful. It must go terribly wrong in order to see "Needs investigation" label. This is because these thresholds are hard-coded. It would be great to configure these thresholds
7 votes -
6 votes
-
Why can't we see the historical crash statistics
Recently I find that we can only check the recent four days' crash data even I select 'past 30 days', is there anything wrong? or why we are not allowed to check historical crash data?
1 vote -
One view for all apps in Crashlytics
In a large project with 10+ apps, you have to select projects one by one to see crashes and all other details. Just like Google Analytics and some others (in the same tool), treat app ids as filters and provide ability to see everything at once.
6 votes -
API Access to Crash and Performance Data.
Provide Crash Free Metric, Performance metrics, Alerts and Insights via API to integrate with existing systems
4 votes -
Split Android & Wear OS app
Since Android & Wear OS must use the same package name to be able to communicate, we have no way to split apart Android & Wear OS crash reports.
This is an issue because we use Flutter for the mobile app and Kotlin/Jetpack Compose for the Wear OS app. The two apps share essentially nothing in common except for the package name and we have two separate teams working on them.Filtering for device type sounds like it should work, but the we only have phone & tablet in that list even though there's at least one crash guaranteed to…
1 vote -
Crashalytics to support SDK
I need crashlytics to track crashes of my SDK not the crashes of the app which is implementing my SDK
1 vote -
Apply filters from crash issues list (eg. state = open) to the graphs above.
This can be either done by directly adding the filter option to the graphs above, or by a toggle which applies filters from the list to the graphs. (not by default, to prevent confusion/regression from current behaviour)
1 vote -
Add event ids for browser viewing into Crashlytics BigQuery tables
I had trouble with finding a specific crash event in the group of crashes. BigQuery gave me an event_id, but I was not able to use this id in the URL query param to open a specific crash in browser. Browser event ids and bigquery event ids are different. Not sure if I’ll need it in the future again, but it was a bit annoying to get all the threads and stacktraces from bigquery
2 votes
- Don't see your idea?