Skip to content

General

General

Categories

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

33 results found

  1. In the Crashlytics console you can filter crashes based on version, however it would be nice when you select multiple versions to have a comparison graph rather than a combined graph (something like Analytics does with time periods) so that I can confirm that crashes are resolved in newer versions.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. Currently, Crashlytics does not support integration with Jira Server (on premise) v9.0+. I suggest that also this variant of Jira is supported since everybody isn't running Jira Cloud.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  7. 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.

    7 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  8. 6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  9. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  11. I need crashlytics to track crashes of my SDK not the crashes of the app which is implementing my SDK

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  12. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  13. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Crashlytics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
2 Next →
  • Don't see your idea?