Inbound Integrations

Integrations are dynamic and flexible. The integration process is simple and involves two steps:

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

​

How Integrations Work

To create a new integration, simply navigate to the Integrations tab and click on the `Create New Integration button.

From there, give your integration a name, such as “AWS Amazon CloudWatch” if you’re connecting to this tool. You’ll also need to choose which team the integration should belong to, as this can’t be changed later. Finally, select the type of integration, such as “AWS Amazon CloudWatch”. Keep in mind that the integration type can’t be changed later.

​

Configuring Integrations

Configuring integrations is a two-step process:

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

Step 2 is identical for each integration type, while step 1 (receiving the payload) differs for each integration type.

We’ll walk you through these steps by the example of a Webhook Integration.

​

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. Muted: For muted integrations, you will receive a payload and we’ll create an incident. However, we won’t send any notifications.

3. 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.

5. Here, you can also find the integration’s URL

1. Now it’s time to look at the Payload Mapping tab.
2. You can see payloads that were received by All Quiet in the left pane and select them as a template / example for your attribute mapping.
3. 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.
4. Below you can find the mapping component that maps the payload to an All Quiet incident. More on that, below.
5. We always show a live preview of an incident created from payload and mapping, so you always get immediate feedback when configuring the mapping.
6. You can trigger test incidents to see if everything works as expected and save your mapping.

To send a payload to your Webhook, issue the following cURL command to send a form post to a webhook integration. The payload will show up under the field Latest Payloads. Please note that you need to adjust the URL to your unique integration’s URL.

curl -X POST 'https://allquiet.app/api/webhook/5a6b3505-89f0-48c4-807f-3a41398d8e30' \
-H 'Content-Type: application/json' \
-d '{"alertName": "My Monitor", "alertStatus": "Failed", "description": "From cURL"}'

Learn more about generic webhooks here: Connect Generic Webhooks.

​

Triggering Dummy Incidents

To get a practical understanding of All Quiet’s incident handling, you have the option to initiate a dummy incident. This feature allows you to simulate a real incident by using the current request payload example alongside your established mapping configurations.

When you trigger a dummy incident, the system will execute all the usual processing steps. This includes sending out notifications to your teams and managing any outgoing integrations. This simulation is an effective way to experience firsthand how All Quiet will respond in an actual operational scenario. It’s an invaluable tool for verifying that your configurations and mappings will behave as expected during a live incident.

Here’s how to trigger a dummy incident:

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

To map a payload’s JSON to an actual incident you need to define a set of mapping rules. Those rules are also defined in JSON. To allow you to conveniently configure your mapping your changes to the JSON are automatically applied to a preview of an incident.

Teams are a means of organizing collaborators (team members) and integrations.

• Each user can be a member of multiple teams.
• Each integration belongs to exactly one team.
• Each incident triggered by an integration is thus available for collaboration only to the members of the integration’s team.

​

How does attribute mapping work?

With attribute mapping you can map the payload of your integration to the defined data structure of All Quiet’s incidents.

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 the following example the attribute Status is first mapped by a jsonPath and then by a map evaluation.

​

Handling multiple payloads

If your payloads can have different structures, you can define multiple attributes for the same field/name. The first attribute that can be evaluated sunccessfully to a value will be used.

​

Quick Example

Let’s assume, we’ve created an integration of type Webhook. We can use the following CURL command below as an example to trigger the webhook:

curl -X POST 'https://allquiet.app/api/webhook/5a6b3505-89f0-48c4-807f-3a41398d8e30' \
-H 'Content-Type: application/json' \
-d '{"alertName": "My Monitor", "alertStatus": "Failed", "description": "From cURL"}'

Then, we can map the payload to an incident with this attribute mapping:

{
  "attributes": [
    {
      "name": "Status",
      "mappings": [
        {
          "jsonPath": "$.jsonBody.alertStatus"
        },
        {
          "map": "Failed->Open,->Resolved"
        }
      ]
    },
    {
      "name": "Title",
      "mappings": [
        {
          "jsonPath": "$.jsonBody.alertName"
        }
      ]
    },
    {
      "name": "Severity",
      "mappings": [
        {
          "static": "Critical"
        }
      ]
    },
    {
      "name": "Description",
      "mappings": [
        {
          "jsonPath": "$.jsonBody.description"
        }
      ]
    }
  ]
}

Which brings us to this All Quiet incident.

​

Reserved and required attributes

You can map as many attributes with any name you like. There are a few reserved and required attributes though:

​

Optional, additional attribute Keys

{
  "attributes": [
    {
      "name": "Image",
      "isImage": true
      "mappings": [
        {
          "jsonPath": "$.jsonBody.url"
        }
      ]
    }
  ]
}

​

Evaluation Types

Each attribute must hold exactly one of the following evaluation types:

​

Variables

You can use variables in any of your mappings like this {{ previousIncident.status }}. Variables are evaluated once all mappings within an attribute have been evaluated. The names are case-insensitive.

You can reference the current incident with {{ currentIncident.someAttributeName }} and the previous incident with {{ previousIncident.someAttributeName }}.

​

Common examples

​

Combine strings of other attributes

To combine the values of the “Category” and “Threshold” attributes use the following attribute mappings:

{
  "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

Extract elements by property To get the value of the “Return-Path” field of the “headers” array, use $.headers[?(@.field=='Return-Path')].value for the following JSON:

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

​

XPath examples

Extract elements by preceding tag value To get the value of the “Server” field, i.e. the value of the td that follows a td with value “Server” use //table/tr[td='Server']/td[2] for the following HTML:

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

​

Regex examples

• Extract value after colon
• Extract value after specific label
• Extract value before colon

Any label here: my-server

​

Duplicating Integrations

If you want to create a new integration based on one you’ve already set up, you can duplicate it via the inbound integrations overview.

​

Built-in Integrations

Receive alerts from your observability tools. We offer generic email and webhook as well as a growing number of pre-built integrations:

​

Propose a new integration

Didn’t find your tool here? Upvote or add your preferred integration to our roadmap, and we’re happy to ship it. 🚢