API Integration Advanced Settings

At the bottom of an Integration page, you will find an expandable list of Advanced Settings where you can make additional configurations for an integration. Depending on your AlertOps package, you may not have access to all of the options below:

Rules for Opening and Closing an Alert

Use Rules for Opening and Closing an Alert to access, add, or change the underlying field mapping for an integration to open and close an alert. This section will explain the high level use case for Rules for Opening and Closing an Alert. Please visit Advanced Field Mapping for more information on leveraging field mapping.

Auto Grouping of Alerts

In the case of alert updates, an open alert may have follow-up notifications appended to the original alert to reduce alert noise. AlertOps can combine, or group, multiple alerts with the same value for Source, Source Name, and Source Id respectively. An alert received with an "Open" value for SourceStatus will create a notification and all other alerts with the matching Source, Source Name, and Source Id will be appended to the existing alert. These updates can be viewed in the messages or status changes section of an alert.

In example image above, a signal from Alerta will produce an alert and notification only when the source id and source name are unique. Any matching signals with be appended to existing alerts. 

Open Alert When

This setting is where you can configure the source and value that AlertOps will parse from incoming data to trigger an alert.  In the example above, you can see that a new alert will be triggered when the body of an incoming integration email contains a value of 'open'.

Close Alert When

Most sources support auto-closing. This is when a closing event is sent to match the open event. In this case, AlertOps will automatically close the existing alert when an incident matches an existing open alert and also contains the 'close' Value. 

Custom Messaging

Under the alert mapping options, there are several fields to create rich messages for your alerts and notifications. These options will vary based on your AlertOps package, as well as the integration type. Each of these fields can include static text or dynamic variables. 

Email integrations allow you to configure a Subject Text for email subject, as well as a sample email body for testing the integration.

The Short Text and Long Text fields are not required, but it is recommended that you configure each of these.If there is no Long or Short Text field configured, AlertOps will use the entire JSON body as the Message text. You can customize the text fields using a combination of static and dynamic text.

• Short Text Field: The Short Text is the message used in SMS and voice notifications. If there is no short text, AlertOps will use the long text as the Short Message text.
• Long Text: The Long Text / Long Message is the message used in Email and Push notifications.

You can also include an attachment in the form of a URL by selecting the Attachments box. You can send one or more URLs in an array structure. Enter the field name surrounded by brackets.

• Base Path: enter the value for the base path in the incoming URL data.
• URL: enter the value for the URL in the incoming URL data. AlertOps can send the URL as a clickable link in an email notification, or users can click the link in the web app.
• File Name: enter the value for the file name in the incoming URL data.

Alert Delaying/Grouping Options

Alert Delaying

Often times, customers want to delay alerts for various reasons. One use case might be to ignore flapping incidents that will self-resolve, such as a network router periodically experiencing intermittent connectivity issues. During these flapping incidents, the router's status fluctuates between "up" and "down" multiple times within a short span of time, triggering alerts each time the status changes. To address this, we can introduce an Alert Delay tailored to your specific requirements. 

The Alert Delaying feature offers a variety of delay settings for alerts. First toggle Delay at the top of this screen.

• Delay notification for (n) number of incidents received within (n) minutes.
• Delay notification for (n) number of incidents received.
• Delay notification for (n) minutes.
• Delay notification until support hours begin. By selecting this option, you can then define the period of time in which users will receive alerts.

Example: The IT team has determined that each network issue produces 5 alerts in 1 minute and has implemented an Alert Delay to reduce noise.  

Group

Grouping limits the amount of alerts that can flood in from incidents that occur at the same time from the same source. Incoming incidents will merge with the opened alert and prevent multiple notifications for grouped incidents.

Most monitoring systems, for example, generate multiple alerts when a critical server goes down. These alerts might include notifications for CPU usage, disk space, and network connectivity issues. Instead of receiving separate notifications for each individual alert, you can configure the AlertOps integration to group these alerts together based on time frame.  

Example: Alerts received from this integration will be grouped if they all come in within the same 3-minute span.  

Filters to Match Incoming JSON/Form Fields

Filtering alerts in AlertOps allows you to selectively process relevant alerts based on specific criteria. This feature helps customize incoming alerts and prioritize those that are important to your operations. For example, if you receive alerts from a monitoring system for various events, you can use filters to forward only critical server failures affecting specific servers, or with a severity above a certain threshold.  

You can set the Field and Value to filter incoming JSON data. 

• The "Match All Filters" requires all conditions must be true. 
• The "Match Any Filters" simply requires just one of the conditions to be matched. 
• Note that the "Match All" and the "Match Any" filters together constitute an ‘OR’ condition. ONLY when the Match All Filters are not satisfied will the filter evaluate the Match Any conditions if both are present.

The Type dropdown has the options of "Contains" and "MatchesRegex" to select how you would like to configure the matching of the filter.

Example: In this example, incoming JSON data from this integration includes a field called “severity”. This filter will only produce an alert if the “severity” field contains a value of “CRITICAL”.

Escalation Policy Override

Time of Day

An Escalation Policy Override is set at the Integration level and will supersede an associated Escalation Policy based on the time an alert is generated. This feature allows for different applied Escalation Policies at different intervals. 

For example, you can apply a different escalation policy during normal business hours and a separate escalation policy for nights or weekends. With time-of-day escalation policy override, these changes between policies will happen automatically and seamlessly.

Example: Alerts coming through on Sunday and Saturday will be emailed to the Manager per the applied Escalation Policy Override.

Source Data

In other cases, an Escalation Policy needs to be updated dynamically based on key values coming from the JSON data which you can set using the Source Data feature. By utilizing the source data escalation policy override feature, you can define specific rules or conditions based on the source of the alert. For example, you may set up different escalation policies for alerts originating from your production servers compared to those from your development or testing environment.  

Example: If incoming JSON data contains a field named "severity" with a value of “CRITICAL”, alerts will be blasted to all hands per the applied escalation policy override.   

Dynamic Recipient Groups

Dynamic Recipient Groups gives the option to change recipient groups based on key values from incoming JSON data.

For large organizations with multiple departments, it’s important to ensure that when an alert is triggered, it is routed to the appropriate department or team based on the nature of the issue. With dynamic recipient groups, you can define rules or conditions that determine which group should receive the alert. For instance, you may set up rules based on keywords in the alert description or source data, such as "network" or "database." When an alert matches these conditions, it is automatically routed to the corresponding department or team responsible for handling such issues.  

Example: In this example, if incoming JSON data contains a field named "issue_name" with a value of "network" then the Infrastructure Team will be alerted.