Skip to content

General

General

Categories

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

29 results found

  1. 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)
  2. 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)
  3. 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.

    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)
  4. 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)
  5. 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)
  6. 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)
  7. 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)
  8. 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)
  9. 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

    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)
2 Next →
  • Don't see your idea?