Inbound Integrations

1. Set up integration
2. Receiving a payload
3. Mapping payload attributes to incidents

​

How Integrations Work

​

Configuring Integrations

1. Receiving a payload
2. Mapping payload attributes to incidents

​

Receiving Payloads

1. After creating a new integration, we find ourselved on the Edit tab of the integration details page. Here, you can make some important high-level adjustments.
2. Is your integration unreliable, sometimes triggering incidents that auto-resolve just minutes later? Or would you prefer to suppress incidents during specific times and have them surface later? Reduce noise and minimize stress for your on-call colleagues. Team Administrators can enable Snooze Settings for the integration.
   • When activated, newly created incidents are automatically snoozed. They will only alert on-call members once the snooze window ends or if the incident is manually unsnoozed. Choose between two modes:
     • Snooze mode Relative: Snooze incidents for a specified timeframe, e.g. 10 minutes.
     • Snooze mode Absolute: Snooze an incident until a specified time of day. By default, the incident will unsnooze the next time (“Next Possible”) the selected time is reached after the snooze period ends. Optionally, you can choose a weekday to specify exactly when it should unsnooze.
   • While snoozed, there are no auto-escalations, and no notifications are sent regarding the incident.
   • Once unsnoozed - no matter if manually or because the snooze window ends - Tier 1 on-call members are alerted and any potential auto-escalations will begin.
   • If an incident resolves itself during the snooze period, it remains snoozed and does not alert your team.
   • To view and manage snoozed incidents, enable the Include Snoozed filter in the incident overview.
3. Here, Team Administrators can add Maintenance Windows for the integration.
   • Muted: For muted integrations, you will receive a payload and we’ll create an incident. However, we won’t send any notifications.
   • Maintenance: For maintenanced integrations, you will receive a payload. However, we won’t create an incident nor will we send any notifications.
4. Once you’ve created an integration of type Webhook, you can send HTTP requests to the integration’s URL. Every request sent to this address will show up as a new payload in the Payload Mapping tab (see below), from which we’ll extract attributes and map these to incidents. Moreover, you can adjust the authentication setting for your URL.

1. Now it’s time to look at the Payload Mapping tab.
2. You can find the webhook URL you need to send alerts to All Quiet above the tab.
3. You can see payloads that were received by All Quiet in the top row pane and select them as a template / example for your attribute mapping.
   Cannot find your payload? Check, if you sunccessfully connected the integration. Also, we can only receive webhook requests that are smaller than 3mio bytes (3MB).
4. The payload will always be in JSON format and wrap other formats like HTML or XML depending on your payload. We show the JSON in a json-edit-react component for better visability and usability.
5. Below you can find the mapping component that maps the payload to an All Quiet incident. More on that, below.
6. We always show a live preview of an incident created from payload and mapping, so you always get immediate feedback when configuring the mapping.
7. You can trigger test incidents to see if everything works as expected and save your mapping.

curl -X POST 'https://allquiet.app/api/webhook/12fa90f1-9f01-41a8-8fe5-b5d385dac03d' \
-H 'Content-Type: application/json' \
-d '{"alertName": "My Monitor", "alertStatus": "Failed", "description": "From cURL"}'

​

Triggering Dummy Incidents

1. Navigate to the Payload section, where you’ll see your saved request payload for testing.
2. Review your Mapping settings to ensure they’re correctly configured to simulate the desired incident conditions.
3. Click on Trigger Dummy Incident to start the simulation. You’ll observe the full cycle of incident processing as if it were a genuine alert.

​

Mapping Payloads

​

How does attribute mapping work?

​

Quick Example

curl -X POST 'https://allquiet.app/api/webhook/12fa90f1-9f01-41a8-8fe5-b5d385dac03d' \
-H 'Content-Type: application/json' \
-d '{"alertName": "My Monitor", "alertStatus": "Failed", "description": "From cURL"}'

1. We can see all attributes. We will evaluate all attributes from first to last element. Learn more about reserved and required as attribute types below.
2. For each attribute in attributes we will evaluate all mappings from the first to the last element. The result of a mapping will be passed on to the next mapping element as an input. The last result will be the attribute’s value. In this example, the attribute Status is first mapped by a jsonPath and then by a map evaluation. See below for more about our evaluation types and mapping variables.
3. You can mark each attribute with Grouping, Hide in Previews or Image key. More on this, here.
4. You can add further attributes for customization anytime.
5. Below, you will always see a live preview of your All Quiet incident based on the current mapping.

​

Handling Multiple Payloads

1. We will first check if the JSONPath $.query.utm contains the value Medium or High to define the Severity.
2. If none of those values can be found, we will use the second Severity attribute in our mapping to set the Severity to Minor.

​

Payload Mapping in Terraform

• Template Download (Example with Integration_ID = “Datadog”): https://allquiet.app/api/integrations/terraform/default/Datadog.tf.
• Each Integration_ID can be found here: https://allquiet.app/api/public/v1/inbound-integration/types

​

Reserved and required attributes

​

Optional, additional attribute Keys

​

Evaluation Types

​

Variables

​

Common examples

​

Combine strings of other attributes

{
  "Attributes": [
    {
      "Name": "Category",
      "Mappings": [
        {
          "Static": "Alerts"
        }
      ]
    },
    {
      "Name": "Threshold",
      "Mappings": [
        {
          "Static": "42"
        }
      ]
    },
    {
      "Name": "Combined",
      "Mappings": [
        {
          "Static": "The category is {{ currentIncident.category }} with a threshold of {{ currentIncident.threshold }}"
        }
      ]
    }
  ]
}

​

JSONPath examples

{ "headers": [{ "field": "Return-Path", "value": "" }] }

​

XPath examples

<body>
    <table>
        <tr>
            <td>Severity</td>
            <td>Critical</td>
        </tr>
        <tr>
            <td>Server</td>
            <td>prod1</td>
        </tr>
    </table>
</body>

​

Regex examples

Any label here: my-server

​

Duplicating Integrations

​

How to Use One Integration For Several Teams

1. Create a “Root” team. This team is only used to create integrations that are shared across several teams. There should be no on-call schedules for your Root team.

2. Create the integrations you want to share across multiple teams in your “Root” team.

3. Create advanced routing rules in the root team. Define for which conditions incidents are assigned to different teams. Below, you can find examples of different routings for incidents created via “Root” team’s AWS CloudWatch integration. In the payload mapping, we added the attribute “Team”. Based on the values of the attribute, we route incidents to different teams:
   1. Condition: Team = Core → Then Action: Assign to Team “Core” → Escalations in Team “Core” start
   2. Condition: Title = Backend → Then Action: Assign to Team “Backend” → Escalations in “Backend” start

1. Notice that the incident was created in the “Root” team, the team associated with the AWS CloudWatch integration.
2. As the incident included the attribute “Team” with value “Core”…
3. …the incidents was instantly assigned to “Core” team…
4. …and Core’s Tier 1 members were notified.

​

Built-in Integrations

​

Propose a new integration

​

API and Webhook Rate Limits