Customize your alerts on your favorite tools.
You can set up your alerts based on your own thresholds and control which crashes to get notified on.Instabug enables you to customize your alerts to cover your use cases of when you’d like to get alerted and where to get alerted.

Alerts and Rules

If you’d like to get alerted as soon as you receive any crash, you will be able to do that through our “Alerts and Rules” engine.

Go to “Alerts and Rules”

That will redirect you to our Alerts and Rules engine, now you can click on Create to start creating a new rule:

That will take you to the Rules engine where you can control the conditions for which you’d like to be alerted, and the integrations where you’re alerted.

Alert type

Since we’re talking about Crash Reporting use cases, select “Crashes” from the first drop down list and then you have several use cases you can apply.

Alert Triggers

The covered use cases to be alerted for crashes are:

• When a crash is first seen
• When a new occurrence of an existing crash is seen
• When regression is detected: when a closed crash is reactivated on a newer app version
• When a spike is detected:
  - Number of occurrences within time exceeds a certain threshold
  - Number of affected users within time exceeds a certain threshold
  - Number of occurrences and affected users within time exceeds a certain threshold (a combination of the
  above 2 spikes is detected)
• When 1% of the sessions of the app crash in the last 24 hours

Now let’s take an example for each one of the use cases and walk you through how to set it up:

Use Cases for Crash Alerts

A crash is first seen

You’d like to be alerted whenever a crash is first seen. An example how this can be used:
As soon as you release a new version, you can get notified the moment a crash appears on the app.

You would be able to satisfy this use case by setting a rule as shown on the following screenshot:

To create teams and specify Team Ownership, please refer to our Team Ownership Product Guide.

##When a new occurrence of an existing crash is seen
You can get alerted whenever a new occurrence of an existing crash is seen. If a crash is persistent and affects more than a single user, this may need your attention. You can set that up by changing the trigger to “A new occurrence of an existing crash is seen”

Regression detection - when a closed crash is reactivated on a newer app version

This makes sure that you can see regression as soon as it happens. If you had resolved a crash on a previous app version and it reappears on a newer version, you can set up that alert. From your triggers list, select: "A closed crash is reactivated on a newer app version”

Spike detection - by number of occurrences or by number of affected users, or both

Often, if a spike in the number of occurrences happens, you'd like to get alerted. Whether that spike is in the number of occurrences or the number of users affected by those crashes, you have control over that threshold.
Number of occurrences within time
You can control this by choosing the trigger to be “Number of occurrences within {time}” so you would control the time frame for which this becomes alarming and the number of occurrences that would be worth an alert.
The following screenshot describes what it would look like.

Number of affected users within time
When the number of users concern you and you’d like to get alerted whenever a threshold is surpassed, you can choose the trigger to be “Number of users with {time}”

Number of occurrences and affected users within time
You can have a combination of both Number of occurrences and Number of affected users as your threshold.

When a crash affects 1% of your current app version’s sessions in the last 24 hours

According to our user’s research, a lot of the developers will only start worrying about a crash if it has affected more than 1% of the sessions on a specified day. Instabug also covers this use case by giving you the option to be notified if that condition is satisfied.

Alert conditions

Along with the use cases mentioned above, you can control the way your team is being alerted by targeting specific parts of the app, specific teams, versions, tags, priorities, types of crashes or even experiments running on the app.
Below is a list of the attributes that you can use within your rule to satisfy that, you can also use more than a single attribute on the same rule, (for example, if you’d like to be alerted regarding Out Of Memory crashes on a specific app version).

Attributes:

• App version
• Exception Message
• Team
• Path
• Filename
• Crash type
• Tags
• Status
• Assignee
• Priority
• Total affected users
• Total occurrences count
• Experiments
• App status