Alerts Conceptual Guide

The Alerts feature is a notification system that enables better insights into issues such as a payment failure in Orders or an attributes import failure in Product Catalog.

You can create an alert from scratch, or use a preconfigured alert template to get started.

This topic covers the conceptual information behind the three main components of an alert: Alert trigger conditions, the Look-back period, and the Severity threshold.

​

Alert Trigger Conditions

Alert trigger conditions consist of a series of statements that define the circumstances that trigger an alert. In these statements, you establish the components of an alert by selecting a fabric application, a service within that application, an attribute of that service, an operator, and a value for which you would like to set up the alert. When configuring these statements, you can use a variety of parameters, such as order statuses, inventory levels, and transaction outcomes, to create customized trigger conditions that meet your specific monitoring requirements.

It is important to note that when you are setting up an alert in Copilot, the values displayed in each field are entirely dependent upon the selection in the previous field.

The following table outlines the fields in the Alert trigger conditions section, and their values.

​

Alert trigger conditions example

As an example of how you can use the fields in alert trigger conditions to create statements, consider the Payments Failure Alert template. It’s an alert that’s generated from the Orders application whenever an invoice fails.

There are two statements required to create this alert; an if statement and an and statement. The if statement simply says, “if the Orders app invoicing service created an invoice more than two hours ago.” To create this statement in the alert trigger conditions, the if statement is configured as follows:

• App: is set to Orders
• Service: is set to Invoice
• Attribute: is set to createdAt
• Operator: is set to GT
• Add value: is set to NOW() - PT2H

This statement tells Alerts where to look and when, but what it’s looking for - the failed invoice - is incomplete. The and statement finishes the alert trigger condition by describing the type of invoice to look for. It says, “the status of the invoice includes the values _failed_ or _settlement failed_.” To create this statement in the alert trigger conditions, the and statement is configured as follows:

• Service: is set to Invoice
• Attribute: is set to statusCode
• Operator: is set to IN
• Add Values: is set to FAILED and SETTLE_FAILED

Understanding alert trigger conditions is crucial for setting up effective alerts in your fabric applications. By configuring both if and and statements, you can specify the exact conditions that trigger an alert.

​

Adding and removing conditions

When creating an alert from scratch, you can refine your alert trigger conditions by adding and statements. This allows for even more nuanced and targeted alerting, so that you can specify combinations of attributes, operators, and values that must be met to trigger an alert. However, every condition for all your statements must be met to trigger the alert, which means too many and statements could cause you to miss an event that you want to monitor.

​

Look-Back Period

The look-back period is the timeframe that fabric considers when assessing data for potential alerts.

For instance, if an alert is configured to trigger when order processing times exceed a certain threshold, the look-back period could be defined as the past 24 hours. In this scenario, fabric examines order processing times over the last day to determine if the current processing time deviates significantly from the average.

Configuring the look-back period helps provide context to alerts. A shorter look-back period may capture recent changes or sudden spikes in activity, while a longer look-back period can help identify sustained trends or recurring issues.

​

Severity Threshold

The Severity threshold is the term for the required number of events to occur for an alert to be considered low, medium, or severe.

• Low Severity: Alerts with a low severity threshold are triggered when the specified event occurs infrequently. These alerts typically highlight events that might require attention but may not be of immediate concern.

• Medium Severity: A medium severity threshold indicates a moderate frequency of the event. Alerts in this category often point to events that may warrant closer monitoring due to their increased occurrence as a potential issue that should be addressed.

• High Severity: Alerts with a high severity threshold are triggered when the specified event reaches a significant frequency. These alerts usually require immediate attention, as they typically signify critical events or issues that require prompt resolution to prevent impact on business operations.

You can configure the severity threshold numbers to tailor alerts to your specific needs.

Keeping with the example of the Payments Failure Alert, you could set the Low Severity field in this template to five. This will generate a low severity alert when five payments have failed within the time frame you specified. From there, you could set Medium Severity to 10, so that a medium severity alert would be generated when 10 payments fail within your time frame. Setting High Severity to 15 would generate high severity alert when 15 payments have failed within your time frame.

You will need to adjust the severity thresholds until you get the alert dialed in to your needs. Typically, you want to avoid infrequent or minor events and focus on frequent and severe events. Adjusting the severity threshold will help you strike a balance between being notified of potential issues and avoiding unnecessary alert fatigue.

​

Related Topics

• Alerts Overview
• Alerts Homepage
• Creating an Alert
• Creating an Alert from a Template
• Managing Alerts