# Alerting For Crash Reporting 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.Luciq 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”

2874 — *Go to the Alerts & Rules page from the Luciq menu*

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

All Crash Reporting triggers 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](/product-guides-and-integrations/product-guides/automation-and-workflows/team-ownership.md). #### 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.\ \&#xNAN;*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. Luciq 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

*A list of conditions that you can choose from to have finer control over your alerts*

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.luciq.ai/product-guides-and-integrations/product-guides/automation-and-workflows/alerts-and-rules/alerting-for-crash-reporting.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.