# Public API
Source: https://docs.allquiet.app/advanced/api

Our Public API allows you to manage your resources from anywhere.

### US Hosted API (allquiet.app)

* Swagger Documentation: [https://allquiet.app/api/public/swagger-ui/index.html](https://allquiet.app/api/public/swagger-ui/index.html)
* JSON: [https://allquiet.app/api/swagger/public-v1/swagger.json](https://allquiet.app/api/swagger/public-v1/swagger.json)

### EU Hosted API (allquiet.eu)

* Swagger Documentation: [https://allquiet.eu/api/public/swagger-ui/index.html](https://allquiet.eu/api/public/swagger-ui/index.html)
* JSON: [https://allquiet.eu/api/swagger/public-v1/swagger.json](https://allquiet.eu/api/swagger/public-v1/swagger.json)

### Plan Requirements

The Public API is not available in the STANDARD plan, but is included in both PRO and ENTERPRISE plans. If you're on the STANDARD plan, you'll need to upgrade to access the API functionality.

### Authentication

To use the API, you need an API Key that you can create for your organization. This is the same API Key you use for SCIM or the Terraform provider.

You can authenticate your API requests in two ways:

1. Using the `X-Api-Key` header:

```
X-Api-Key: your-api-key-here
```

2. Using the standard Authorization Bearer token:

```
Authorization: Bearer your-api-key-here
```

Both methods are equivalent - choose the one that best fits your needs.


# Auditing
Source: https://docs.allquiet.app/advanced/auditing

Track every action, ensure compliance, and gain full visibility into your All Quiet account.

<Note>
  <strong>Auditing is an available add-on for Enterprise plan users only.</strong><br />
  To upgrade to the Enterprise plan, please contact <a href="mailto:support@allquiet.app">[support@allquiet.app](mailto:support@allquiet.app)</a>.
</Note>

## Full Visibility with Auditing

All Quiet's Auditing feature empowers your organization with comprehensive visibility into every action taken within your account. Designed for security, compliance, and operational transparency, auditing helps you:

* Track changes to incidents, users, integrations, and settings
* Monitor who did what, when, and from where
* Meet compliance requirements and internal policies
* Investigate issues and ensure accountability

## Key Capabilities

* **Comprehensive Event Logging:** Every significant action—such as incident updates, integration changes, and team updates—is recorded in a secure, tamper-evident log. We also log any updates for SCIM or Terraform provisioned users.
* **User Attribution:** See exactly which user performed each action with timestamps
* **Search & Filter:** Quickly find specific events using powerful search and filtering tools (by user, team, etc.).
* **Export Logs:** Download audit logs for compliance, reporting, or further analysis.

## Public API

Audit logs can also be accessed via the [Public API](/advanced/api) for automated integration and export workflows.

* `GET /api/public/v1/auditlog/list`
* `GET /api/public/v1/auditlog/{auditLogId}`

You can browse these endpoints in our Public API Swagger UI at

* US Region: `https://allquiet.app/api/public/swagger-ui/index.html`.
* EU Region: `https://allquiet.eu/api/public/swagger-ui/index.html`.

## SIEM integrations & export

The audit log system supports automatic integration or export of data to market-leading SIEM tools such as New Relic, SentinelOne, QRADAR, SPLUNK, RAPID7, and Wazuh.

## How to Access Auditing

1. Navigate to the **Auditing** section in your All Quiet Web dashboard (Available on Enterprise plan only).
2. Use the search and filter options to review activity across your organization.
3. Export logs as needed for your records or compliance audits.

<Note>
  Audit logs are retained according to our organization's records retention policy. For custom retention periods, please contact support.
</Note>

## Example Use Cases

* **Security:** Investigate suspicious activity or unauthorized changes.
* **Compliance:** Demonstrate adherence to regulatory requirements (e.g., SOC 2, ISO 27001).
* **Operational Oversight:** Review changes to integrations, escalations or user permissions.

***

When enabled, audit logs are visible for "Organization Owners" and "Organization Admin" roles.

For more information or to enable Auditing for your organization, please reach out to <a href="mailto:support@allquiet.app">[support@allquiet.app](mailto:support@allquiet.app)</a>.


# Live Call Routing
Source: https://docs.allquiet.app/advanced/live-call-routing

Configure how inbound calls are routed to on-call responders after your number is connected

<Info> In All Quiet, Live Call Routing is only available for the Pro and Enterprise plan. **Organization Administrators** and **Organization Owners** can create Call Routing Numbers. **Team Administrators** can edit existing numbers whose **Root Team** is a team they administer — but cannot create new ones.</Info>

<Note>
  Live Call Routing in All Quiet is **Bring Your Own Number (BYON)**: you keep (or provision) your phone number with Twilio, and All Quiet routes incoming calls to the right responders.<br /><br />
  To set up Live Call Routing, start with ordering a phone number from Twilio and connecting it with your All Quiet account. You can find the instructions in our [step-by-step guide for Twilio](/integrations/inbound/twilio).<br /><br />
  After that, you can set up Live Call Routing in All Quiet by following the steps in this documentation page.
</Note>

## Overview

This guide picks up where the [Twilio integration setup](/integrations/inbound/twilio) leaves off. That guide walks you through buying a number, creating a Call Routing Number in All Quiet, and connecting your Twilio credentials. Once the connection shows a green checkmark, you are ready to configure **how** incoming calls are handled — caller allow & block lists, welcome messages, routing modes, dial chains, voicemail, and fallbacks.

Here you will learn:

* How a call flows from the welcome message through the on-call chain to a connected responder or voicemail. It also explains **when and how incidents are created for incoming calls**.
* What each setting on the **Call Routing** tab does, and how to tune them for your team.
* What snoozing, maintenance, and mute do — and what they **don’t** affect for live calls.
* How to block or allow callers in the **Call Routing** tab — and what to watch for if you also filter at your provider (Twilio).

<Info>
  Open your Call Routing Number in All Quiet and switch to the **Call Routing** tab when you configure settings. All options described under [Call routing tab](#call-routing-tab) live there.
</Info>

### Prerequisites

Before configuring Live Call Routing, make sure:

1. **Twilio is connected** — you completed the steps in the [Twilio integration guide](/integrations/inbound/twilio) and the integration shows a valid connection.
2. **Your team has [on-call schedules](/essentials/escalations#schedules) and [escalation tiers](/essentials/escalations#escalation-tiers)** — call routing uses the same on-call chain as incident escalations, not a separate call-specific policy.
3. **On-call members have [confirmed phone numbers](/essentials/channels#sms-and-phone-calls) on their All Quiet profiles** — only members who are online and have a phone number configured can be dialed.
4. **You have permission to configure the number** — creating a Call Routing Number requires **Organization Administrator** or **Organization Owner** rights. **Team Administrators** can edit call routing, Twilio settings, and operational tabs for numbers whose **Root Team** they administer.

### Quick mental model

**Call routing is always live.** When someone dials your number, All Quiet routes the call according to your Call Routing settings. Integration snooze, maintenance windows, and mute mostly affect **incidents** and alert notifications — they do not stop the phone from ringing. See [What snoozing, maintenance, and mute do](#what-snoozing-maintenance-and-mute-do-and-don’t-do) for details.

## How a call flows

Before you tune individual settings, it helps to understand the end-to-end path of an inbound call. The diagram below shows every step; the numbered list underneath explains how All Quiet builds the on-call dial chain and how incidents are created.

```mermaid theme={null}
flowchart TD
    A[Caller dials your number] --> BL{Allowed by allowlist / blocklist?}
    BL -->|No| R[Reject — call blocked]
    BL -->|Yes| B[Welcome message]
    B --> C{Keypad menu?}
    C -->|Yes| E[Caller presses key]
    C -->|No| DV{Send directly to voicemail?}
    E --> DV
    DV -->|Yes| VM[Record voicemail → Open incident created]
    DV -->|No| D[Resolve on-call chain for team]
    D --> F[Dial person in on-call chain]
    F -->|No answer / busy| H{More people in chain?}
    H -->|Yes| F
    H -->|No| I{Voicemail enabled?}
    I -->|Yes| J[Record voicemail → Open incident created]
    I -->|No| K[Play closing message → hang up, missed call, no incident created]
    F -->|Answers + accepts| L[Bridge call to responder]
    L -->|Call ends| M[Close call and create Open or Resolved incident]
```

1. **Caller allow & block lists** — When the call reaches All Quiet, the caller’s number is checked against your [allowlist and blocklist](#caller-allow-%26-block-lists). Blocked callers, or callers not on the allowlist when one is set, are rejected before routing begins.
2. **Welcome message** — The caller hears your configured welcome message (text-to-speech or uploaded audio). In keypad menu mode, this message must explain the menu options.
3. **Route selection** — In single-route mode, All Quiet uses the default route. In keypad menu mode, the caller picks a route by pressing 1–9; invalid keys and timeouts follow your menu settings.
4. **Direct voicemail shortcut** — Once a route is selected, All Quiet checks **Send caller directly to voicemail**. If enabled, the on-call dial chain is skipped: the caller records a voicemail and All Quiet creates a **new open incident** from that recording.
5. **On-call chain & dialing** — If direct voicemail is off, All Quiet resolves who to call from the route’s **Team to route to**, using that team’s on-call schedule and escalation tiers — the same chain used for incident escalations, not a separate call policy.
   * Differences between Live Call Routing Escalations and Incident Escalations:
     * Only online members with a confirmed phone number on their profile are candidates to receive a call.
     * First, Tier 2 members are tried. One person is tried at a time, there is no parallel ring group. We randomly shuffle the order of the members in each tier for each call.
     * [Round Robin](/essentials/escalations#round-robin-alerting) is ignored.
     * If no one in Tier 1 answers the call, Tier 2 members are tried. We ignore if auto-escalations are enabled and we ignore the timeouts between tiers. We simply try the next person that is online in the team's on-call schedule.
     * If [auto-assign](/essentials/escalations#auto-escalations-across-several-teams) is enabled in your team's escalations, it is ignored.
     * [Repeat tiers](/essentials/escalations#repeat-escalation-tier) and [repeat escalations](/essentials/escalations#repeat-escalations) are ignored.
6. **Accept call** — The on-call member hears a prompt and must press 1 before the call is bridged to the caller. This prevents mailboxes and accidental pickups from connecting the caller.
7. **Escalation between people** — If someone doesn’t answer within **Dial timeout per user**, the next person is tried immediately — there is no wait between tiers. **Max users to call** caps how many people are tried before fallback.
8. **Fallback** — When the dial chain is exhausted, the caller hears your voicemail or a closing message. What happens next — incident or call log only — depends on your fallback settings. See [Incidents vs. call logs](#incidents-vs-call-logs) below.

### Incidents vs. call logs

Every inbound call appears in **Call Logs**, no matter how it ends. An **[incident](/essentials/incident)** is only created when the caller leaves a voicemail or when an on-call member **accepts** the call (presses 1 and is bridged to the caller). Other outcomes — such as a **Missed** call where no one accepts and voicemail is disabled — are logged as calls only.

| Outcome                                                                                                                                | Incident? | Status       | Notes                                                                                                                                                                                                                                                                      |
| -------------------------------------------------------------------------------------------------------------------------------------- | --------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Voicemail** (direct shortcut or after no one responds)                                                                               | Yes       | **Open**     | Created when the caller finishes recording. Severity comes from the route’s **Incident severity** setting. If **Attach voicemail transcript to incident** is enabled, the transcript is added to the incident. On-Call members will receive normal incident notifications. |
| **Accepted call** (on-call member pressed 1 and call was bridged) with **Auto-resolve** incident when on-call answers **on** (default) | Yes       | **Resolved** | All Quiet creates a Resolved incident after the call ends. No escalations are started for the on-call members.                                                                                                                                                             |
| **Accepted call** with **Auto-resolve** incident when on-call answers **off**                                                          | Yes       | **Open**     | The incident is created as open after the call ends and follows your team’s normal escalation workflow.                                                                                                                                                                    |
| **Missed call** (closing message, voicemail disabled)                                                                                  | No        | —            | The caller hears the closing message and hangs up. The call is recorded in **Call Logs** only — for example as a missed call with no voicemail.                                                                                                                            |
| **Blocklisted** (caller rejected by allow/block list)                                                                                  | No        | —            | The call is hung up immediately — no welcome message, no on-call dial, no incident. Log step: `CallerBlocklisted`. See [Session outcomes](#session-outcomes).                                                                                                              |
| **Any outcome during a [maintenance window](/essentials/inbound#maintenance-for-inbound-integrations)**                                | No        | —            | The call is still routed normally, but **incident creation is suppressed**. You will find the call in **Call Logs**, but no new incident is created.                                                                                                                       |

<Info>
  Use **Call Logs** to review every inbound attempt — who was dialed, menu choices, voicemail vs. missed, and call duration. Use the **Incidents** tab when you need actionable records that enter your on-call workflow (voicemails and taken calls).
</Info>

### Concurrent inbound calls

When several callers ring at the same time, each call runs through the flow above independently — but they draw from the same on-call members for a team.

If an on-call member is already connected to another **live call** for that team, their phone number is **excluded from the dial chain** for any other inbound call. All Quiet will not ring the same number twice at once.

When every reachable member is already busy, a second caller’s dial chain can be exhausted quickly — the same outcome as when no one answers. If **Send to voicemail if no one responds** is enabled, that caller is sent to voicemail. This is expected behavior, not a misconfiguration. For high-volume hotlines, keep voicemail fallback enabled so concurrent callers can still leave a message.

The sections below walk through each setting on the **Call Routing** tab and how it maps to this flow.

## Call routing tab

Now that you know how a call moves through All Quiet, open the **Call Routing** tab on your Call Routing Number to configure each step.

The tab is divided into four sections:

1. **[General settings](/advanced/live-call-routing#general-settings)**: Configure the general settings for the call routing number.
2. **[Routing modes](/advanced/live-call-routing#routing-modes)**: Configure the routing modes for the call routing number. Choose between [single route](/advanced/live-call-routing#single-route-default) and [keypad menu mode](/advanced/live-call-routing#keypad-menu-mode).
3. **[Per-route settings](/advanced/live-call-routing#per-route-settings-route-editor-modal)**: Configure the per-route settings for the call routing number. Choose the team to route to, the incident severity, and the caller fallback.
4. **[Caller allow & block lists](/advanced/live-call-routing#caller-allow-%26-block-lists)**: Allow or block callers by phone number or country prefix before routing begins.

<img />

### General settings

The general settings for your call routing number are:

1. **Caller ID shown to responders**: Show caller number vs. your inbound Twilio number. Helps responders recognize repeat callers vs. hotline number. <Tip>We recommend showing the twilio number as the receiver can save it to their contacts for future reference and do not disturb overrides.</Tip>
2. **Attach voicemail transcript to incident**: When enabled, voicemails are transcribed and attached to the resulting incidents.
   <Note> Currently, Call transcripts are generated in **English only** — if callers use another language, consider disabling this option. The incident is created as soon as the voicemail is recorded; the transcript is added afterward and can take a few moments to appear on the incident via an update.</Note>
3. **Welcome message**: The message that is played to the caller before they are routed to the on-call chain. This can be a text-to-speech in your preferred language or uploaded audio file. <Tip> In [keypad menu mode](/advanced/live-call-routing#keypad-menu-mode), you should explain keypad options here. </Tip>

<img />

### Routing modes

Per default, incoming calls are sent to a single route in you integration's root team. You can configure this in the **Routing modes** section.

#### Single route (default)

One team, one route. Good for a single hotline. Click on the route to edit it. The [route editor modal](/advanced/live-call-routing#per-route-settings-route-editor-modal) will open.

<img />

#### Keypad menu mode

The keypad menu mode allows the caller to pick a route by pressing a number between 1 and 9. it is activated by clicking on `+ Add another keypad option` while in single route mode.

1. You can see your routes and there current settings. Caller presses 1–9 to pick a route (e.g. “Press 1 for production, 2 for billing”).
2. Define timeouts and tries for the caller in the keypad menu
   * **Menu keypad timeout**: Seconds to wait for input before re-prompting.
   * **Menu prompt attempts**: How many times the menu is played before hanging up (including timeouts or wrong keys).

<img />

### Per-route settings (route editor modal)

When clicking on a route, the route editor modal will open.

It is divided into four sections:

1. **[Routing](/advanced/live-call-routing#routing)**: Configure the team and severity for the route.
2. **[Caller fallback](/advanced/live-call-routing#caller-fallback)**: Configure what should happen if no one answers the call for the route. Or, send the caller directly to voicemail.
3. **[On-call dialing](/advanced/live-call-routing#on-call-dialing)**: Configure the on-call dialing for the route. How many users are tried, how long to wait for each user to answer, and what happens if someone answers the call.
4. **[Accept call](/advanced/live-call-routing#accept-call)**: Configure how on-call members are required to accept the call for the route. To prevent mailboxes from answering calls, **on-call members are always required to press 1 before the call is bridged to the caller**.

<img />

#### Routing

These settings define which team handles the call and how the resulting incident is classified.

1. **Team to route to** — Select the team whose on-call members should be dialed when this route is used. You can choose between your integration's root team and other teams within the root team's organization — which teams appear in the list depends on your role. **Team Administrators** can select teams they administer; **Organization Administrators** and **Organization Owners** can select from all teams in the organization. All Quiet builds the dial chain from that team’s [on-call schedule and escalation tiers](/essentials/escalations) — the same chain used for incident escalations. In keypad menu mode, each menu option can route to a different team.
2. **Incident severity** — Set the severity for incidents created from this route (answered calls and voicemails). Use this to distinguish a production hotline from a lower-priority line, or to align call-based incidents with your existing severity workflow.

#### Caller fallback

These settings control what happens when no one answers, or when you want callers to reach voicemail without dialing anyone.

**Send caller directly to voicemail** — When enabled, All Quiet skips the [on-call dial chain](/advanced/live-call-routing#on-call-dialing) entirely and sends the caller straight to voicemail. Useful for after-hours lines, overflow numbers, or routes where you only want to collect messages. You can add a custom voicemail message here that is played after the [welcome message](/advanced/live-call-routing#general-settings). Choose between text-to-speech in your preferred language or uploaded audio.
<Note> Max length for the voicemail message is 2 minutes. </Note>

<img />

If **Send caller directly to voicemail**  is disabled, you can configure what happens when no one answers the call after trying the [on-call dial chain](/advanced/live-call-routing#on-call-dialing).

**Send to voicemail if no one responds** — When enabled, callers who reach the end of the dial chain (everyone tried within **Max users to call** did not answer and accept the call) are sent to voicemail instead of hearing a closing message and hanging up. This is the most common fallback for operational hotlines. If disabled, the caller will hear a closing message and hang up.

<Note> Max length for the voicemail message is 2 minutes. </Note>

<img />

**Voicemail message** — The message played before the caller can leave a voicemail. Applies when direct voicemail or “no one responds” voicemail is active. Can be text-to-speech or uploaded audio.
**Closing message** — The message played when the dial chain is exhausted and voicemail is **not** enabled. After this message, the call ends. The call is logged in **Call Logs** as a missed call; **no incident is created**. See [Incidents vs. call logs](#incidents-vs-call-logs).

#### On-call dialing

These settings fine-tune how All Quiet walks through the on-call chain and what happens when someone picks up.

**Auto-resolve incident when on-call answers** — Enabled by default. When an on-call member accepts and the call is bridged, All Quiet creates an incident that is **automatically resolved** when the call ends. Turn this off if you want answered calls to leave an **open** incident that enters your team’s normal escalation workflow. See [Incidents vs. call logs](#incidents-vs-call-logs) for a full breakdown.

**Skip numbers already dialed in this call** — When enabled, All Quiet will not ring the same phone number twice during a single inbound call session. Helps avoid calling the same person again if they appear in multiple escalation tiers.

**Max users to call** (1–10, default **3**) — Caps how many on-call members are tried across all escalation tiers before fallback (voicemail or closing message). Increase this for larger teams or longer chains; keep it lower if you want callers to reach voicemail quickly when the first few people are unavailable.

**Dial timeout per user** (5–120 seconds, default **20**) — How long All Quiet waits for each person to answer before moving to the next person in the chain. There is no additional delay between tiers — the next person is dialed immediately after the timeout. Shorter timeouts reach voicemail faster; longer timeouts give responders more time to pick up (e.g. when they need to find a quiet place).

<img />

<Tip>Start with the defaults (max **3** users, **20** seconds per user) and adjust based on your team size and how quickly callers should reach voicemail. See [How a call flows](#how-a-call-flows) for how these settings fit into the overall call path.</Tip>

#### Accept call

Before bridging the caller to an on-call member, All Quiet requires the responder to confirm they are ready to take the call.

**“Press 1 to accept call” message** — The prompt played to the on-call member when their phone rings (text-to-speech or uploaded audio). They must press **1** on their keypad to accept; only then is the caller connected. Reduces accidental pickups and wrong-number answers on shared devices. Also, this prevents mailboxes from answering calls.

**Accept call keypad timeout** — How long the on-call member has to press 1 after hearing the prompt before All Quiet treats the attempt as unanswered and moves to the next person in the chain.

**Prompt attempts** — How many times the accept prompt is repeated before giving up on that person and dialing the next candidate.

<img />

### Caller allow & block lists

The fourth section on the **Call Routing** tab lets you filter callers by phone number or country prefix before routing begins. Filtering runs when the call has already reached All Quiet — after your provider (e.g. Twilio) forwards it to us.

Both **Allowlist** and **Blocklist** use the same entry format:

* One entry per line or comma-separated
* Full numbers in [E.164 format](https://www.twilio.com/docs/glossary/what-e164) (for example `+4915124688123`) or country prefixes (for example `+1`, `+49`)

1. **Allowlist (Whitelist)** — If set, only callers whose number matches an entry on the allowlist (full number or prefix) are allowed through. If the allowlist is empty, all callers are allowed unless blocked by the blocklist.

2. **Blocklist** — Blocks matching numbers or prefixes. The blocklist takes precedence over the allowlist — a number that appears on both lists is blocked.

<img />

<Warning>
  All Quiet filtering runs **after** your provider accepts the call. Make sure you do not have contradictory allow/block rules in Twilio — calls only reach All Quiet if Twilio lets them through.
</Warning>

<Check>You've successfully set up Live Call Routing in All Quiet. You're now able to receive inbound calls and route them to the right responders.</Check>

## Operational tabs

After configuring call routing, use these tabs on your Call Routing Number to review what happened on your hotline. They complement each other: **Call Logs** capture every attempt; **Incidents** capture only what enters your on-call workflow. See [Incidents vs. call logs](#incidents-vs-call-logs) for when each applies.

### Call Logs

Call logging in All Quiet works on **two levels**:

1. **Call session** — one row per inbound call (the **Call Logs** list).

2. **Log entries** — a step-by-step timeline inside that session (**View logs**).

Every inbound call creates a session, whether or not an incident is created.

#### Call session list

The list shows a summary for each call. You can filter by **caller number** (prefix match) and **outcome**.

| Column                         | What it shows                                                                                                                                                                                   |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Started / Ended / Duration** | When the call began, when it finished, and total duration                                                                                                                                       |
| **Caller**                     | The caller’s phone number                                                                                                                                                                       |
| **Outcome**                    | Final result badge — see [Session outcomes](#session-outcomes) below                                                                                                                            |
| **Voicemail**                  | Download link if a recording was captured                                                                                                                                                       |
| **Incident**                   | Link to the incident, if one was created — from the incident, open **[Call Logs](/essentials/incident#incident-details-call-logs)** in the Properties sidebar for the same session and timeline |
| **Logs**                       | Opens the [detailed timeline](#view-logs-session-detail) for that call                                                                                                                          |

<img />

#### Session outcomes

These badges answer **“What happened to this call?”**

| Outcome         | Meaning                                                                                                                                                                                                                   |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Ongoing**     | The call has not finished yet.                                                                                                                                                                                            |
| **Accepted**    | An on-call member answered **and pressed 1 to accept**; the call was bridged to the caller. Picking up without pressing 1 does **not** count as Accepted.                                                                 |
| **Voicemail**   | The caller left a voicemail — either via [direct voicemail](/advanced/live-call-routing#caller-fallback) or after no one responded with voicemail fallback enabled.                                                       |
| **Missed**      | The call ended without anyone accepting and without a voicemail recording — for example dial chain exhausted with only a [closing message](/advanced/live-call-routing#caller-fallback).                                  |
| **Blocklisted** | Caller was rejected by the [allow/block list](#caller-allow-%26-block-lists) before routing. No welcome message, no on-call dial, no incident. Log step: `CallerBlocklisted`.                                             |
| **Failed**      | Reserved for sessions explicitly marked as failed. Most calls resolve to **Accepted**, **Voicemail**, or **Missed** instead. You might want to check your provider (e.g. Twilio) logs as well to see why the call failed. |

#### View logs (session detail)

Click **View logs** on a session to open:

1. **Session summary** — caller, outcome, timestamps, provider call ID, voicemail download (if any).
2. **Chronological log table** — one row per processing step: webhook received, dial chain built, dial attempt, voice command sent, and so on.

<img />

Use this view when troubleshooting routing — for example “Why wasn’t person X rung?” or “Why did this call go to voicemail after only one attempt?”

#### Reading the log timeline

Each log row has a **Step** (where the call was in the flow), an **Action**, and a **Result**. The most useful steps when reading a call:

| Step                                        | When it appears                                                                                                                                                |
| ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **CallReceived**                            | A new inbound call arrived; the session was created.                                                                                                           |
| **CallerBlocklisted**                       | Caller failed the [allow/block check](#caller-allow-%26-block-lists). Call ended immediately; no further routing steps are logged.                             |
| **GatherDtmf**                              | Waiting for the caller to press a menu key ([keypad menu mode](/advanced/live-call-routing#keypad-menu-mode)).                                                 |
| **DialChainResolved**                       | All Quiet computed who will be dialed and in what order. **Start here** to see the full on-call dial list.                                                     |
| **DialTarget**                              | About to ring an on-call member.                                                                                                                               |
| **DialTargetResult**                        | Result of that dial attempt — explains in plain language why it succeeded or failed (timeout, busy, answered but did not press 1, accepted and bridged, etc.). |
| **ConfirmTarget** / **ConfirmTargetResult** | The on-call member heard the “press 1 to accept” prompt and their response.                                                                                    |
| **Voicemail** / **RecordMessage**           | Caller was sent to voicemail or is recording a message.                                                                                                        |
| **Hangup**                                  | Call is ending (closing message or clean hang-up).                                                                                                             |

**Actions** on each row:

| Action               | Meaning                                                                                     |
| -------------------- | ------------------------------------------------------------------------------------------- |
| **Webhook Received** | Your provider (Twilio) sent a status update.                                                |
| **Command Sent**     | All Quiet sent a voice command back (play prompt, dial, gather keypad input, etc.).         |
| **Internal**         | Internal processing only — for example resolving the dial chain or analyzing a dial result. |

**Results:** **Processed** (step handled), **Failed** (something went wrong — see error details in the row), or **Ignored** (webhook received but no action taken).

<Note>A log row with **Result = Failed** is not the same as session outcome **Failed**. A single failed processing step can still end with the call marked **Missed** or **Voicemail**.</Note>

<Tip>When debugging a call, read **DialChainResolved** first (who was eligible), then each **DialTargetResult** (what happened per attempt), then **Voicemail** or **Hangup** (how the call ended).</Tip>

#### Retention

| Data                                                 | Retention                                                                  |
| ---------------------------------------------------- | -------------------------------------------------------------------------- |
| **Detailed log entries** (timeline in **View logs**) | **365 days** — shown in the UI as “Call logs are retained for 365 days.”   |
| **Voicemail recordings**                             | **365 days** — download links stop working after the recording is removed. |
| **Call session summaries** (list rows)               | Kept for 365 days automatic expiry                                         |

<Tip>When a caller reports they couldn’t get through but no incident was created, check **Call Logs** first. Missed calls, exhausted dial chains, and calls during maintenance all appear here — but not in the **Incidents** tab.</Tip>

### Call Stats

**Call Stats** aggregates call sessions on this number over time — volume, duration, and breakdown by **outcome** (**Accepted**, **Voicemail**, **Missed**, **Blocklisted**, **Ongoing**, and **Failed**). Use it to spot trends: Are most callers reaching a responder? How often does voicemail kick in? Is missed-call volume rising after a schedule change? How many callers are being rejected by your allow/block lists?

The same outcome badges from the [Call Logs](#session-outcomes) list drive these statistics, so numbers in **Call Stats** match what you see per call in **Call Logs**.
Call logs are retained for 2 years.

<img />

### Incident Report

The [Integration-level Incident Report](/advanced/report#integration-level) shows [incidents](/essentials/incident) **created from this number** — not every call. Only **voicemails** and **successfully accepted calls** produce incidents; **Missed** outcomes appear in **Call Logs** only.

### What snoozing, maintenance, and mute do (and don’t do)

This section clarifies a common misconception: these controls only **affect incindents** resulting from Calls, but not the call routing itself.

| Control                      | Affects live calls?               | Affects incidents?                                                                                                                                                   |
| ---------------------------- | --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Snoozing**                 | No — calls still route to on-call | New incidents create after the call ends or voicemail is left can be [snoozed](/essentials/inbound#snoozing-inbound-integrations); call routing itself is unaffected |
| **Maintenance**              | No — calls still route            | **New incident creation is suppressed** during maintenance windows; the call still happens, but you will not get an incident record                                  |
| **Muted**                    | No                                | Affects [incident/notification behavior](/essentials/inbound#maintenance-for-inbound-integrations), not the inbound call path                                        |
| **Pausing the phone number** | **Not in All Quiet**              | N/A                                                                                                                                                                  |

#### Pausing or disabling the number in Twilio

All Quiet has no “pause this number” toggle for Call Routing Numbers (unlike [Ping Monitor](/integrations/inbound/ping-monitor) or [HTTP Monitoring](/integrations/inbound/website-http-monitoring)). To temporarily stop callers from reaching All Quiet, adjust the webhook in **Twilio Console**:

**Temporarily pause inbound calls (keep the number)**

1. Open [Twilio Console](https://console.twilio.com/) → **Phone Numbers** → **Manage** → **Active numbers** and select your Live Call Routing number.
2. Under **Voice configuration**, find **A call comes in** (also labeled **Incoming Voice Call**).
3. Replace the All Quiet webhook with one of the following:
   * A **TwiML Bin** or **TwiML App** that plays a short “this line is unavailable” message and hangs up.
   * A **Twilio Function** that rejects the call (`<Reject/>`).
   * Clear or change the webhook so traffic no longer reaches All Quiet.

Callers will no longer enter the All Quiet routing flow until you restore the webhook.

**Resume routing to All Quiet**

When you are ready to go live again, make sure there's no webhook configured in Twilio Console in **A call comes in** for your number. Then, open the **Twilio Settings** tab on your Call Routing Number in All Quiet and **save** your integration settings. All Quiet re-applies the correct voice webhook on your Twilio number. Confirm under **A call comes in** in Twilio Console that the webhook points back to All Quiet, then place a test call.

## Recommended defaults & tuning guide

A practical “start here” table:

| Scenario                      | Suggested settings                                                                                                        |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| Small team, single hotline    | Single route, max users = tier count, voicemail on, auto-resolve on                                                       |
| High concurrent caller volume | Voicemail on, reasonable max users (3–5), accept-call enabled — see [Concurrent inbound calls](#concurrent-inbound-calls) |
| After-hours only voicemail    | Direct voicemail route, or schedule via team availability                                                                 |
| Multi-department              | Keypad menu, one route per team                                                                                           |

## Troubleshooting

### Can I buy a phone number through All Quiet?

**Not currently.** Live Call Routing uses **Bring Your Own Number (BYON)**: you purchase and own the number with a provider such as [Twilio](/integrations/inbound/twilio), then connect it to All Quiet. We do this so you are not charged twice — once by the carrier for the number and again by All Quiet on top. You pay your provider directly for the number and usage; All Quiet handles routing and on-call dialing on top.

### Can All Quiet create incidents for missed calls?

**No.** All Quiet only creates incidents for **voicemails** and **accepted calls** (on-call member pressed 1 and the call was bridged). **Missed** calls — where no one accepts and the caller does not leave voicemail — appear in **Call Logs** only, not in **Incidents**.

If you want a record that enters your escalations when no one answers, enable **[Send to voicemail if no one responds](/advanced/live-call-routing#caller-fallback)** or **[Send caller directly to voicemail](/advanced/live-call-routing#caller-fallback)** on your route. Voicemail recordings create **open incidents**. See [Incidents vs. call logs](/advanced/live-call-routing#incidents-vs-call-logs).

### Call connects but no incident was created

The call was routed and appears in **Call Logs**, but no incident was created. Check whether a [maintenance window](/essentials/inbound#maintenance-for-inbound-integrations) was active — calls still route, but incident creation is suppressed. See [Incidents vs. call logs](/advanced/live-call-routing#incidents-vs-call-logs).

### Nobody gets rung when someone calls the hotline

Verify that on-call members are **online**, have a **confirmed phone number** on their profile, and that the route’s **Team to route to** is correct. Call routing only dials members in that team’s on-call schedule. See [Prerequisites](/advanced/live-call-routing#prerequisites) and [On-call chain & dialing](/advanced/live-call-routing#how-a-call-flows).

### The same person always seems to be rung first

Within a tier, dial order is **shuffled randomly per call** — there is no fixed “first responder.” The same person may be tried first several times in a row by chance; across many calls the order varies.

### A second simultaneous caller always gets voicemail

[Expected when all reachable numbers are busy](/advanced/live-call-routing#concurrent-inbound-calls). On-call members already on a live call for that team are excluded from other dial chains. Enable **Send to voicemail if no one responds** so concurrent callers can leave a message.

### The number still receives calls after “pausing” in All Quiet

All Quiet has no pause toggle for Call Routing Numbers. Pause or disable inbound calls in **Twilio** — see [Pausing or disabling the number in Twilio](/advanced/live-call-routing#pausing-or-disabling-the-number-in-twilio).

## Related docs

* [Connect Twilio with All Quiet](/integrations/inbound/twilio) — number setup and credentials
* [On-call schedules & escalation tiers](/essentials/escalations)
* [Troubleshooting & FAQs — Live Call Routing](/miscellaneous/troubleshooting#live-call-routing)


# Organizations
Source: https://docs.allquiet.app/advanced/organizations

Organizations in All Quiet provide a structured way to manage and coordinate multiple teams under a single umbrella. This feature is particularly useful for larger setups or enterprises where multiple teams need to collaborate and share resources efficiently.

<Note>Organizations are available on Pro and Enterprise plans.</Note>

## Key Features of Organizations

### Roles

Organization Memberships feature three main roles

* `Members` *Organization Members* have automatically *Team Member* rights in all Teams belonging to the organization. This means they can also manage all incidents of the organization's teams. However, to add them to a team’s on-call schedule, you need give these users explicit [team roles](/essentials/teams#roles), additionally.
* `Administrator` *Organization Administrators* have automatically *Team Administrator* rights in all Teams belonging to the organization. This means that on top of being able to manage incidents of all teams, they can also manage all users of the organization's teams. Moreover, they can create overarching policies, such as routing to teams. If applicable, they can also manage the organization's status pages and related serveices.
* `Owner` *Organization Owners* additionally have exclusive rights to manage the organization itself, including member roles and organization settings.

### Cross Team Collaboration

* **Assining Incidents to other Teams an Users**: Incident can be [assigned to specific users](/essentials/incident#assign-to-user), even if they are not on-call. Also, you can assign the incident to [additional teams](/essentials/incident#assign-to-team) if help is needed.
* **[Advanced Incident Routing](/advanced/routing):** Organizations enable sophisticated routing mechanisms that allow incidents to be dynamically assigned to different teams within the organization.
* **Share Integrations across Teams:** [Inbound](/essentials/inbound#how-to-use-one-integration-for-several-teams) and Outbound Integrations can be shared across teams, simplifying the setup and embracing collaboration.

### Security

Leverage [OIDC](/miscellaneous/sso) Login, [SCIM](/miscellaneous/sso#scim-2-0) and [Terraform](/advanced/terraform) provisioning as well as out [Public API](/advanced/api) access control security and centralize user and resource management

### Simplified Organization

Organizations are designed to offer advanced team management and coordination capabilities:

* **Centralized Management:** Simplify the administration of multiple teams by centralizing management tasks under one organization.
* **Scalable Team Dynamics:** As your team or business grows, Organizations make it easier to scale management and operational processes without compromising on efficiency or oversight.

## Should I Use Organizations?

While Organizations offer powerful features for team management and coordination, they are an advanced feature:

* **Optional, Not Required:** Utilizing Organizations is not mandatory to achieve full functionality in All Quiet. They are optional and suitable for users who require advanced management capabilities.
* **Ideal for Multiple Teams:** Organizations are best suited for scenarios involving management of multiple teams, providing tools to streamline administration and incident management across several teams.
* **Consider Your Needs:** It is important to assess whether your current or anticipated team dynamics necessitate the advanced coordination capabilities that Organizations provide. E.g. organizations allow you to share one outbound integration amongst several teams. This allows you to send incidents from differenet teams within your org to the same slack channel, using the same integration.

## What's the difference between Organization & Team Memberships?

At All Quiet, **Team** and **Organization Memberships** are independent of each other.

Users with Organization Memberships have rights for all teams within the organization, allowing them to interact with all incidents. However, they are not part of any schedules, escalations, or rotations, meaning they are never on-call. To include a user in a team's on-call escalations, assign them a specific **Team Membership** in addition to their Organization Membership.

Organization Members are not billed.

Billing is based on the number of unique users with Team Memberships across all teams. You can view all billed users under "Billing & Subscription > Your current usage". Users can have Team Memberships without having Organization Memberships and vice versa.

## Setting Up Your Organization

<Steps>
  <Step title="Create New Organization">
    Navigate to the `Organizations` section in the sidebar and click on `+ Create`.
    <Info>New Organizations can be created by Users who signed up without being invited, as well as Billable Users and *Organization Owners* of existing Organizations.</Info>

    <img />
  </Step>

  <Step title="Name, Select Teams and Create Your Organization">
    1. Enter your organization's name in the `Display Name` field, such as `My Demo Org`.
    2. Next, select the teams you wish to include in your organization. Teams can be modified later through the team's edit form or directly within your organization’s settings.

    As you are creating the Organization, you will become the Organizations Billable User. You can [change the Billable User](/miscellaneous/billing#organizations) later on.

    <img />
  </Step>

  <Step title="Organization created">
    After creating the Organization, you will be redirected to the Organizations overview. From here, after creating your org, you’ll have several options to manage it (1-7).

    <img />
  </Step>
</Steps>

### Edit the Organization

<Info>Editable for *Organization Owners*, viewable for *Organization Administrators* and *Organization Members*</Info>

1. Click `Edit` to access the edit view of your Organization.
2. You can change the orgs `Display Name`
3. You can update the *Billable User* here. Select between all *Organization Owners*
   <Warning> Be careful when changing the *Billable User*. A subscription is attached to a User, not to an Organization. The new *Billable User* will have to resubscribe and create a new subscription. Otherwise, no new incidents will be created for Teams in this Organization. **Exception**: The Trial is still active.</Warning>
4. Click "Save" if you want to keep your changes.
   <img />

### Edit the Teams of the Organization

<Info>Editable for *Organization Owners*, viewable for *Organization Administrators* and *Organization Members*</Info>

1. Click `Teams` to access the view showing all Teams of your Organization.
2. If you are the *Billable User* or an *Organization Owner*, you can update the teams here. Besides the teams already in the organization, you can also add teams that are not currently part of any organization, provided you are the *Billable User* for them. If you want to add teams for which you currently lack the necessary rights, contact their *Billable User* and request that they either add the team to the organization or assign you as the *Billable User*.

<img />

### Manage Organization Members

<Info>Editable for *Organization Owners*, viewable for *Organization Administrators* and *Organization Members*</Info>

1. Click `Members` to access the the member management.
2. To add your colleagues who should have [Organization Roles](/advanced/organizations#roles), click `Invite New`. Remember, this step is only necessary for users who need organizational privileges. User can be part of your Organizations Team withouth have Organization Roles.
3. You can update the Role or remove Organization members, anytime.

   <img />

Clicking `Invite new` opens a layover to invite new members to your organization. You have the option to invite new users who are not yet part of All Quiet, or you can select from a list of users with whom you are already associated within the platform. You can also decide which role they should have in the Organization, *Member*, *Administrator* or *Owner*. Learn more about the difference, [here](/advanced/organizations#key-features-of-organizations).

<img />

### SSO - OIDC & SCIM

<Info>Accessible to *Organization Owners* only.</Info>

To set up OIDC & SCIM, follow this [guide](/miscellaneous/sso).

### Users

<Info>Editable for *Organization Owners*, viewable for *Organization Administrators* and *Organization Members*</Info>

1. On this page you can find all users associated wiht your Organization.
2. You will see all Team and Organization Roles currently assigned to these users.
3. When provisioned via [SCIM](/miscellaneous/sso#scim-2-0) or [Terraform](/advanced/terraform#find-provisioned-users-in-all-quiet), you will see this in the `Source` column.
   <Warning> For compliance reasons, you can delete provisioned users via the frontend. If not necessary, we recommend to not make use of this. Deleting provisioned resources via the Frontend can e.g. destroy your Terraform State. </Warning>
4. For security reasons, you cannot delete yourself via this view, as this can lead to a deletion of the whole org.
5. You can `Delete` other users of your organization.  If a user only has roles within this specific organization and it's teams, their entire All Quiet account will be deleted and anonymized. However, if they have roles in other organizations or teams, their account will remain active — but they will lose all access to this organization’s resources.

<img />

### API Keys

<Info>Accessible to *Organization Owners* only.</Info>

Here, you can create and find the API keys you need to use [SCIM](/miscellaneous/sso#scim-2-0) and [Terraform](/advanced/terraform#create-api-key) with All Quiet.

### On-Call Report

<Info>Accessible to *Organization Owners* and *Organization Administrators*.</Info>

For more info about the on-call report, please read the [On-Call Report documentation](/advanced/report#on-call-report).

### Incident Report

<Info>Accessible to *Organization Owners* and *Organization Administrators*.</Info>

For more info about the incident report, please read the [Incident Report documentation](/advanced/report#incident-report).

## Creating a New Team in Your Organization

The Billable User, *Organization Administrators* and *Organization Owners* can create a new team in an Organization.

<Steps>
  <Step title="Step 1">
    Under `Teams` click `+ Create`.

    <img />
  </Step>

  <Step title="Step 2">
    Pick a team's name. Then, select the organization you want to add the team to. The [Billable User](/miscellaneous/billing#organizations) of the selected Organization will become the new team's Billable User, too.<br /><br /> To create a team in a new organization, [create a new organization](/advanced/organizations#setting-up-your-organization) first. Hit `Create`. Later, Team Name and Organization can be changed, again.

    <img />
  </Step>
</Steps>


# Reports
Source: https://docs.allquiet.app/advanced/report

Get insights into the performance of your team and organization

## Incident Report

Our Incident Report shows the latest incident trends KPIs for your Teams and Organization, comparing them with the previous period.
The report is available on Team and Organization Level.

### Team level

<Info>The Incident Report is visible to all Members of the related Team. If the Team belongs to an Organization, all Users with [Organization Roles](/advanced/organizations#key-features-of-organizations) have access, too.</Info>

Your Team's current incident report can be found in the `Incidents` tab of your Team.

1. Select the Timezone of the Report. Per default, the report shows all times in your [Team's timezone](/essentials/teams#edit-team).
2. Add filter criteria
   1. Per default, the report shows the last 7 days and compares them with the previous 7 days. You can adjust this time interval, anytime.
   2. Additionally, you can filter for Incident `Severity` or `Status`.
3. Download the Report as .csv based on your current filters.
4. Your Team's incident KPIs, comparing the current time interval with the previous.
   1. **Total**: Total Number of Incidents
   2. **Resolved**: Number of Incidents that are resolved, also relative (in %) to the number of **Total** incidents.
   3. **MTTA**: Mean Time to Acknowledge, the average time it took your team to acknowledge new incidents.
   4. **TTA Median**: It’s the middle amount of time it took your team to acknowledge an incident. Half the cases happen faster than this time, and half happen slower.
   5. **MTTR**: Mean Time to Resolution, the average time it took your team to resolve new incidents.
   6. **TTR Median**: It’s the middle amount of time it took your team to resolve an incident. Half the cases happen faster than this time, and half happen slower.
5. The graph showing the amount of incidents per time interval matching your filter criteria
6. Link to the [Engagement Report](/advanced/report#engagement-report).

<img />

### Integration Level

<Info>The Incident Report is visible to *Team Administrators*, *Organization Administrators* and *Organization Owners*.</Info>

This report shows the Incident KPIs for each Inbound Integration. It is available within each Inbound Integration under the “Incidents” tab.
The report works in the same way as the [Team Report](/advanced/report#team-level) described above.

<img />

### Organization Level

<Note>This feature is only available for Organizations, which are part of Pro and Enterprise plans.</Note>
<Info>The Incident Report is visible to *Organization Administrators* and *Organization Owners*.</Info>

You Organization's incident report can be found in the tab `Incidents` within your Organization.
In general, the report works the same as the [Team Incident Report](/advanced/report#team-level).

1. Select the timezone for the report. Per default, it's your local timezone.
2. Download the Report as .csv based on your current filters. The Organization Report has the same filters and default settings as the Team Report, plus you can filter for Teams.
3. Below the graph, you can find a table showing all relevant KPIs on Org Level and per Team.
   1. You can sort the table by any KPI in ascending or descending order by clicking on the column header. This allows you, for example, to quickly identify which team has the most incidents or the highest MTTA.
   2. The Org Level Row always stays on top.

<Tip>Since a single incident can be assigned to multiple teams, the total number of incidents in your organization may not equal the sum of incidents across all teams.</Tip>

<img />

## On-Call Report

<Note>This feature is only available for Organizations, which are part of Pro and Enterprise plans.</Note>

<Info> The On-Call Report is visible to *Organization Administrators* and *Organization Owners*</Info>

This report gives you an overview of your users' on-call times. Here's how you find it & how it works:

1. In the Web App, open `Organizations`.
2. Select the desired Organization and open the 3-dot menu.
3. Click on the `On-Call Report` button.

<img />

1. The Report is available on-demand with flexible date selection and per default features all on-call times of the current month. You can also filter for Teams of your organization and only export on-call times from these teams. The timezone can be used to further fine tune the observed interval. If you have users living in different timezones, this feature helps to determine their actual on-call times for e.g. the month according to their timezone. This can be pretty important for payroll purposes.
2. You can see the on-call times of your organization’s users for the selected interval. Note that only Tier 1 and [Tier 1 fill-up](/essentials/escalations#auto-fill-up-from-higher-escalation-tiers) times are currently represented. If a user is on-call in 2 [different teams](/essentials/teams) of one organization at the same time, the time is still only counted once.
   <Tip> You want to know Tier 2, 3 etc. on-call times? This info is available via our [Public API](/advanced/api).</Tip>
3. **Download** button: Download a .csv of the on-call times for the selected time interval.

<img />

## Engagement Report

<Info> The Engagement Report is visible to all Members of the related Team. If the Team belongs to an Organization, all Users with [Organization Roles](/advanced/organizations#key-features-of-organizations) have access, too.</Info>

The Engagement Report highlights the analytical depth of your team's incident management efforts. Available on-demand through the `Teams > Reports` section in the Web App with flexible date selection, this feature also arrives on a weekly basis in your inbox.
The report is created for each team separately.

<img />

Features:

* **Scheduled Delivery:** Automatically sent every Monday at 7 AM local time for a consistent, timely overview of the past week's activities. Reschedule the delivery in your [team's settings](/essentials/teams#edit-team).
* **Incident Management Summary:** Snapshot of total incidents, percentage of resolved incidents and time with and without open incidents, highlighting effectiveness and responsiveness.
* **Performance Metrics:** Average and median response and resolution times, with details on individual incidents.
* **Team Performance Analysis:** Data analysis on team performance trends, with customizable sections for additional metrics.

### Incident is Managed in 2+ Teams Or Team is Changed

<Note>Available for Pro and Enterprise users only via [assign](/essentials/incident#assign-to-team) action.</Note>

* The incident will only be listed in the report as long as it remains in your team. If you assign an incident that was originally in this team to another team, it will only appear in the other team’s report.
* If an incident was [assigned](/essentials/incident#assign-to-team) to your team after its creation, the values in the report may differ. See the example below.
  * **Example**
    * Incident is created in Team A (t=0 min)
    * Team A, Member 1 acknowledges the incident (t=10 min)
    * Incident is assigned to Team A & B (t=15 min)
    * Team B, Member 2 acknowledges and resolves the incident (t=20 min)
    * **Team A Report**:
      * **Started**: 0 min
      * **Time To Response**: 10 min
      * **First Responder**: Team A, Member 1
      * **Time To Resolve**: 20 min
      * **Resolver**: Team B, Member 2
      * **On-Call (T1)**: Team A, Tier 1 Member(s) when incident was started
    * **Team B Report**:
      * **Started**: 15 min (the point in time when the incident was assigned to Team B)
      * **Time To Response**: 5 min (20 min after creation, 5 min after assignment)
      * **First Responder**: Team B, Member 2 (first responder after assignment)
      * **Time To Resolve**: 5 min (20 min after creation, 5 min after assignment)
      * **Resolver**: Team B, Member 2
      * **On-Call (T1)**: Team B, Tier 1 members, **plus** all notified Team A members, when incident was assigned to Team B in t=15 min


# Advanced Incident Routing
Source: https://docs.allquiet.app/advanced/routing

Add Advanced Incident Routing Rules to Customize your Workflows

<Info> Advance Routing rules can be created an edited by *Organization Owners*, *Organization Administrators* (in Organizations) and *Team Administrators* with Billable User rights (if there are no Organizations). *Team Members* and *Organization Members* have view-only access.</Info>

Advanced incident routing in All Quiet allows technical teams to streamline their workflows by customizing how incidents are handled based on specific conditions and actions. This feature ensures that alerts are managed and escalated efficiently, tailored to the severity and nature of the incident.

<Tip>Best practice: create **one** routing per team and put all routing rules into that routing. Avoid having multiple routings connected to the same team with overlapping rules—if two routings match the same incident type, we can’t infer your business priority and it becomes ambiguous which routing should apply first.</Tip>

Two popular use cases are:

1. Mute channels when `Environment = "TEST"` -> reduce noise for Development/Testing Environments
2. Trigger an outbound webhook only for incidents that have been escalated

You can check out the [examples](/advanced/routing#examples) on this page.

# Setting Up Your Advanced Incident Routing

<iframe title="Introduction to Advanced Incident Routing Rules in All Quiet" />

## Step 1: Create New Routing

<Steps>
  <Step title="Create New Routing">
    To begin setting up your incident routing, navigate to the `Advanced Routings` section in the sidebar and click on `+ Create`.

    <img />
  </Step>

  <Step title="Name and Create Your Routing">
    1. Under `Display Name` enter the name for your routing like "My Routing".
    2. Select the [Team](/essentials/teams) the routing should be applied to. <Note>**Pro and Enterprise plan users**: Select the root team of the routing. Later, you may add the routing to further teams within the root team’s organization. </Note>
    3. Click `Create Advanced Routing`.

    <img />
  </Step>
</Steps>

## Step 2: Select the Teams

<Note> This step is only relevant for Pro and Enterprise plan users. Standard plan users can skip it.</Note>

After creation of the routing, you can see several tabs.

1. `Edit`, where you can change the Routings Display Name
2. `Rules`, where you can add the actual routing rules.
3. `Team Connections`, where you can manage the connected teams.
4. `History`, where you can review [routing execution history](#routing-execution-history-history-tab) for this routing (newest first, with paging).

<img />

In `Team Connections`, you can see that the routing's Root Team is pre-selected. You can add the routing to further Teams within the root Team’s organization. *Team Administrators* can add / remove those Teams they are an admin in, *Organization Administrators* & *Organization Owners* can manage the connections to all Teams of the Organization.

<img />

## Step 3: Add Rules

Now you can start configuring your Advanced Incident Routing by clicking on `+ Add Rule` and configuring your routing rules.

<img />

A pop-up with 3 tabs will appear. [Conditions](/advanced/routing#define-conditions), [Actions](/advanced/routing#configure-actions), [Channels](/advanced/routing#choos-channels). We will walk you through each of them with examples, below.

### Define Conditions

Specify the conditions under which your routing rule should trigger. You can configure the following parameters:

* **Statuses:** Choose between `Open` or `Resolved`.
* **Severities:** Select the severity level such as `Minor`, `Warning`, or `Critical`.
* **Integrations:** Pick the integrated tools that should trigger the rule.
* **Services:** <Info>Only for users of [status pages](/advanced/status-pages).</Info> Pick the affected services that should trigger the rule. If the routing's team or organization has no [services](/advanced/status-pages#create-a-service) yet, you will see a hint to create one first. On plans without Status Pages, a **PRO** badge is shown.
* **Intents:** Filter by the incident's current state, like `resolved`, `escalated`, etc.
  <Tip>If enabled on integration level, [Snoozing](/essentials/inbound#snoozing-inbound-integrations) is applied before routing rules are evaluated, so by the time rules run, the incident is no longer in the “Created” state but already “Snoozed”. So if you want to run a rule once an incident is "created", you might want to include “snoozed” as an additional intent so the rule applies regardless of whether the incident is newly created or already snoozed.</Tip>
* **Labels**: Require labels that appear on the routing team and/or the source integration of the incident. Use Match All (AND) or Match Any (OR) across the labels you list. If this filter is off, all incidents are eligible regardless of labels.
* **Attribute Conditions:** Select the attributes that will trigger this rule. Depending on your selection, the incident's attributes will be matched using **all** (AND logic) or **any** (OR logic) of your selected attributes. Choose from different operators, like `=` , `contrains`, `>` and `<=` to build rules based your attributes' values. In the routing engine, both the attribute name and attribute value comparisons are **not case-sensitive**.
  <Tip> For [Incident Groups](/essentials/incident#incident-grouping): Use the `SubIncidentsCount` attribute to perform actions based on the number of subincidents in a main incident.</Tip>
* **Recurring Time Restrictions:** Restrict the routing rule to certain weekdays and times. Incidents outside this range will not be evaluated by this rule.
* **Absolute Date Restrictions:** Enable a time range in which the rule will be activated. Incidents outside this range will not be evaluated by this rule.

<img />

### Configure Actions

Define the Actions to be executed if the Conditions are met:

* **Discard:** Choose to discard the incident immediately if it meets the defined Conditions.
  * **Auto-Discard In:** Optional setting on **Discard** that controls when a discarded incident is removed from the database. Only available when **Discard** is enabled. Overrides the [Deletion Date](/essentials/incident#automatic-deletion) of the incident. The incident will still exist until `Deleted At`.
* **Change Severity:** Update the incident's severity level.
* **Add Interaction:** Run an incident interaction when the rule matches—for example `Resolve`, `Investigate`, `Reopen`, `Escalate`, `Affects`, `Comment`, `Forward`, or `Snooze`.
  * **Comment:** Shown for `Resolve`, `Investigate`, `Reopen`, `Escalate`, `Affects`, and `Comment` when that interaction is selected. Required only for `Comment`; optional for the others.
  * **Publish Comment:** Appears once comment text is entered. When enabled and the rule runs, the comment is added to the incident. For interactions such as `Affects` or `Resolve`, the comment is published on [status pages](/advanced/status-pages) only if the incident affects a service—the same behavior as when you [publish a comment](/essentials/incident#action-with-comment) manually. Saving with **Publish Comment** on but no comment text is blocked in the UI and rejected by the API.
  * **Affects Services:** <Info>Only if `Affects` was selected as Interaction</Info> Select the affected Service(s). If the team or organization has no services yet, you will see a hint to [create a service](/advanced/status-pages#create-a-service) first (on non-Pro plans, with a **PRO** badge).
  * **Affects Uptime:** <Info>Only if `Affects` was selected and at least one service is selected</Info> Controls whether the incident counts toward [downtime](/advanced/status-pages#affects-uptime). Enabled by default; disable to affect services without lowering uptime.
  * **Forward to:** <Info>Only if `Forwarded` was selected as Interaction</Info> Select the Outbound Integration the incident should be forwarded to.
  * **Snooze for (minutes) & Snooze until:** <Info>Only if `Snooze` was selected as Interaction</Info> Select whether the integration should be snoozed for a certain duration or until a certain point in time.
* **Assign to Teams:** Directs the incident to specified teams. Selecting this option replaces the original incident's team assignment. To retain the original team alongside new assignments, explicitly include it in the selection. Learn more about this incident action [here](/essentials/incident#assign-to-team).
  * **Notify all assigned users & teams**: Decide whether you only want to notify newly assigned users with the "Assign" action or all assigned users and teams, including those previously notified about the incident.
    <Note>Assign to Teams is only available if the routing's team is associated with an organization. Organizations are available on Pro and Enterprise plans.</Note>
* **Add/Set Attributes:** Add attributes to the incident or adjust the value of an attribute under certain conditions. You can also do this in the [payload mapping](/essentials/inbound#mapping-payloads) section of each inbound integration.
* **Delay Actions (min.):** Decide whether to delay the defined actions by a certain number of minutes or not. <Tip>The delayed action will only be executed if the Conditions of this rule are still met at the point in time where the action should be triggered.</Tip>
* **Rule Flow Control:** Decide whether to continue with subsequent rules or whether all subsequent rules should be skipped if this rule is triggered.

<img />

### Choose Channels

Determine how notifications are sent out by configuring Channels based on the Conditions:

* **Mute all Channels:** Silence notifications across all channels (not including outbound integrations, see below).
* **Channels:** Select only specific channels (SMS, Email, Voice Call, Push Notification) that should be triggered when conditions are met, e.g. you can define that only for the conditions you set an SMS is sent.
* **Mute all Integrations:** Silence notifications across all **outbound integration**.
* **Outbound Integrations:** Select only specific outbound integrations that should be triggered when conditions are met, e.g. you can define that only for the conditions you set a generic outbound is triggered.

<img />

### Examples

Here are two examples of how teams are setting up Advanced Incident Routing with All Quiet

<AccordionGroup>
  <Accordion title="Use Case 1: Mute channels when Environment = TEST">
    In this example:

    * The Conditions are
      * Status is `Open`
      * Severity is `Critical`
      * The attribute condition is: Attribute `Environment` = `Test`.
    * Actions are
      * Change Severity to `Warning`
    * Channels chosen are
      * Only `Email` Channel is chosen

    <img />
  </Accordion>

  <Accordion title="Use Case 2: Trigger Generic Outbound for escalated incidents">
    In this example we set two rules in order to only trigger our webhook outbound integration for incidents that have been escalated.

    **Our first rule:**

    * Condition is that an incident is `Open`
    * For Channels we select only our Slack integration and not our Webhook integration
    * We select `Continue with subsequent rules`

    **Our second rule:**

    * Condition is that incidents are `Open` & `Escalated`
    * Action is that we change the Severity to `Critical`
    * We now select both Channels, our Slack integration and our Webhook outbound integration

    This means that only once an incident has been escalated (both manually and automatically) the status will automatically change to `Critical` and we will trigger our outbound webhook integration.

    <img />
  </Accordion>
</AccordionGroup>

## Step 4: Finalize Your Incident Routing

You can add multiple rules and connect them with either `Continue with subsequent rules` or `Skip subsequent rules`. Rules are evaluated top to bottom and each matching rule is executed once per incident. The order can be changed per drag-and-drop, anytime. You can edit, clone or delete individual rules and reorder the rules you have defined to create custom workflows and make All Quiet work for your team.

<Tip> Give each rule a unique display name. This way, you can see exactly which rule of the route was triggered during an incident.</Tip>

<img />

<Tip>All rules can be exported in Terraform format.</Tip>

## Routing execution history (History tab)

<Note>Routing execution history is available to all users that have view or edit access to the routing.</Note>

To open the routing execution history, go to **Advanced Routings**, open a routing, and select the **History** tab (alongside **Edit**, **Rules**, and **Team Connections** where your plan shows it).

All Quiet records **routing rule executions**: whenever advanced routing logic is evaluated for an incident, the system can log **which routing and rule** were involved, **what outcome** occurred (for example executed, delayed, or discarded), and a **snapshot** of the rule’s conditions, actions, and channels plus the **effect that actually applied** (teams, severity, discard, notification mute flags, and so on).

You can inspect this in two places that show the **same underlying execution logs**, scoped either **by routing** (this tab) or **by incident** ([Routing rule executions](/essentials/incident#incident-details%3A-routing-rule-executions) in incident details).

<h3>
  Retention & Availability
</h3>

* **Retention**: logs are kept for **30 days** from creation of each entry, then removed automatically.

<Note>On **Enterprise** plans, retention may differ if your organization agreed on a custom period — contact [support@allquiet.app](mailto:support@allquiet.app).</Note>

### What the Routing Execution History Shows

Executions for **this routing** across all incidents are listed **newest first**, with **Load more** paging.

| Column              | What you see                                                                                                                               |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **Time**            | When the execution was recorded.                                                                                                           |
| **State**           | Outcome of the run, for example **Executed**, **Delayed**, **Delay expired**, or other outcomes such as discarded where applicable.        |
| **Rule name**       | Which rule ran; rows can be [**expanded**](/advanced/routing#expanded-row-details) for the full **rule snapshot** and **applied outcome**. |
| **Actual effect**   | Short summary of what changed (assignments, discard, severity, forwards, snooze, attributes, and similar).                                 |
| **Incident action** | The incident **intent** tied to that execution when present (for example assigned, escalated).                                             |
| **Action time**     | Timestamp of the related incident event when present.                                                                                      |
| **Incident**        | Link to the incident; the app can open the incident’s routing-executions view from there, if the user has access to the incident.          |

<img />

#### Routing States

The **State** column summarizes what happened when the rule was evaluated:

| State             | What it means                                                                                                                                                        |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Executed**      | The rule’s **Conditions** matched and its **Actions** and **Channels** were applied to the incident.                                                                 |
| **Delayed**       | The rule matched, but its actions are scheduled to run later because **Delay Actions (min.)** is set. The actual changes have not happened yet.                      |
| **Delay expired** | A previously **Delayed** run reached its scheduled time but **did not execute** — typically because the rule’s conditions were no longer met when the delay elapsed. |
| **Discarded**     | The rule matched and **Discard** removed the incident immediately (Auto-Discard In = **Immediately**), so no further routing or notifications applied for that pass. |

<Tip>For **Delayed** runs, expand the row to see the configured delay in minutes; for **Delay expired**, the **Applied outcome** panel explains that no changes were made on the incident.</Tip>

<Tip>When **Discard** uses a delayed **Auto-Discard In**, the execution is logged as **Executed** (the incident still exists until `DeletedAt`). The **Actual effect** summarizes the scheduled removal (for example “Incident scheduled for discard in 1 hour”).</Tip>

### Expanded Row Details

Expanding a row shows the same structure as in the incident modal:

* **Conditions** — statuses, severities, integrations, intents, services, labels, attributes, time and date restrictions, and so on, as captured at execution time (with names resolved where possible).
* **Actions** — for example assign teams, change severity, add interaction (snooze, forward, and similar), set attributes, discard, auto-discard in (when discard uses a delay), rule flow (continue versus skip subsequent rules), **delay actions** (minutes).
* **Channels** — notification channels (or muted) and outbound integrations (or muted).
* **Applied outcome** — what actually happened on the incident after the rule was applied: discard, severity change, assigned teams, affected services, forwards, snooze until, added interaction, set attributes, notification mute flags, and similar.

<img />

### Who Can See Execution History

| Location                               | Access                                                                                                                                                                                                                              |
| -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Routing → History**                  | Only users who may **access the team that owns the routing** can open the routing and its execution history. Routing is authorized **per team**.                                                                                    |
| **Incident → Routing rule executions** | Only users who may **view that incident** can open incident details and load executions. The sidebar entry appears when the incident is returned for an **authorized** incident view, consistent with other incident-only features. |

Users who have **View** (read-only) access to a routing still see the **History** tab; it is not limited to editors.

<h2>
  Custom Routing Order
</h2>

In addition to the order in which rules are evaluated within a routing, you can also control the order in which routings are evaluated when an incident arrives.

On the **Advanced Routings** list, use the drag handle on the left to reorder routings when reordering is available.

<img />

**How it works:**

* Drag routings up or down to set priority. Order is saved automatically ("Saving routing order…").
* Routings are processed top to bottom instead of alphabetically by name. Just like within [each routing, rules are processed top to bottom](#step-4-finalize-your-incident-routing).
* Routings without a custom position still appear after ordered ones, then by name.

<Note>Reordering is available only when you can edit **every** routing shown in the (filtered) list. Reordering is disabled if any routing is provisioned or not editable because you are not an Organization Owner, Organization Administrator, or Team Administrator in the routing's root team.</Note>

<Tip>Run high-priority automations — such as [snooze-similar rules](/essentials/incident#snooze-similar-incidents) — before general routing logic, with predictable behavior.</Tip>

**Limitations:**

* Reordering requires **more than one** routing and edit access to **every** routing in the current list.
* **Provisioned** routings cannot be reordered.


# Status Pages
Source: https://docs.allquiet.app/advanced/status-pages

Learn how to share incident updates instantly with your customers, using our Status Pages.

<Note>Status Pages are available on Pro and Enterprise plans.</Note>

<Info> Status Pages are public by default. Switch any page to private and manage access controls from the **Access Control & Private Status Page** section. </Info>

## Set Up Your Status Pages

Your Status Pages will show the current states of your Services. At All Quiet, each of your Services will receive a unique status graph that you can add to your Status Pages. So in order to create a Status Page, we need to create a Service, first.

### Create a Service

<Info>Only *Organization Owners* and *Organization Administrators* have the permissions to create and edit Services. *Organization Members* can edit maintenances for the Services and have view-only access to the Services overviews.</Info>

To create a Service, you first need to create an [organization](/advanced/organizations).

1. Then, select `Services` in the Web App.
2. Click `+ Create`

<img />

To create a Service, fill out the following form.

1. Select a `Display Name` for the Service. It will only be used internally, not publicly on your Status Pages.
2. Select the `Organization` of the Service. Only Incidents created in Teams that belong to this organization can [affect](/essentials/incident#affects-services) this Service.
3. Select the `Public Title` of the Service. When adding this Service to a Status Page, this name will [appear](/advanced/status-pages#your-public-status-page) on the Status Page and in incident update emails to Status Page subscribers.
4. Add a `Public Description` of your Service, [visible](/advanced/status-pages#your-public-status-page) on the Status Page, next to the status graph of the Service.
5. `Create Service`

<img />

#### Auto-Connect Incidents with Your Services and Status Pages

Keep your customers informed effortlessly and automatically let incidents from your integrations [affect](/essentials/incident#affects-services) your Services on your Status Pages, ensuring real-time updates without manual effort.

You can find the `Linked Integrations` section at the bottom of the corresponding Service’s page of the Web App.

<img />

Clicking the `+ Link Integration` button opens an overlay.

1. Select the integration that you want to link with this Service.
2. Select the incident severities that should automatically affect this Service when incidents for this integration are created.
   <Tip>We only consider the initial severity set when the incident is created. Manually changing the severity later will not affect the link between the incident, the Service, and the associated Status Pages.</Tip>
3. Click `Link Integration` to save your changes.

<Check>From now on, incidents from this integration will auto-affect your Service and will be visible on Service's Status Pages. You will see the auto-affect as a [routing rule](/advanced/routing) in the [incident's history](/essentials/incident#incident-history)</Check>

<img />

You can edit (1) and add (2) your Service's linked integrations, anytime.

<img />

#### Team Connections for Services

By **default**, each Service is **automatically connected to all Teams within your Organization**.

You can customize these connections using the **Team Connections** tab for any selected Service. Once configured, future incidents can only affect the Service if they are associated with the connected Teams.

<img />

<Note>
  * Removing a team connection from a Service will also **disable routing rules** for that team that previously affected this Service (see [Routing](/advanced/routing))
  * When [assigning](/essentials/incident#assign-to-team) an incident that is already [affecting](/essentials/incident#affects-services) a Service from a team that is connected to the Service to a non-connected team, the incident will continue to affect the Service.
</Note>

#### Add Message Templates to Service

In the case of an incident, Status Pages offer real-time updates for your customers. To give more context, you might want to add a message if an incident is [affecting](/essentials/incident#affects-services) a Service.
As every second counts during the incident response, you can create message templates that you can easily copy and paste in the event of an incident.

You can find the `Template` section at the bottom of the corresponding Service's page of your web app.

To add a new template, click `+ Add Template`.

<img />

1. Add a `Display Name`, that will be used internally.
2. Prepare the message template that can be used when an incident [affects](/essentials/incident#affects-services) this Service.
3. Click `Add Template`

<img />

1. You can see the template you created.
2. `Save` your changes.

<img />

Next time when selecting the [affect](/essentials/incident#affects-services) action for an incidents, you will see the Template.

1. Select the Service that you created the template for
2. You will see the related templates.
3. Per click, you can add the text from the template as commment.
4. Select `Publish Comment` to publish the comment on your Status Pages and send it in an email to your subscribers.

<img />

### Create a Status Page

<Info>Only *Organization Owners* and *Organization Administrators* have the permissions to create and edit Status Pages. *Organization Members* can edit maintenances for the Services and have view-only access to the Status Page. They cannot see the Status Page's subscribers.</Info>

After creating at least 1 Service, we can create our first Status Page.

1. Select `Status Pages` in the Web App.
2. Click `+ Create`

<img />

To create a Status Page, fill out the following form.

1. Select a `Display Name` for the Status Page. It is used **only inside All Quiet** (not on the public page). If you **do not** set a **Public Title** under [Public Appearance](/advanced/status-pages#public-appearance-of-status-page), this Display Name is used as a **fallback in emails and SMS** to subscribers when the Status Page must be named in those messages.
2. Select the `Organization` of the Status Page. Only Services belonging to this organization can be displayed on the Status Page.
3. Select the Services that you want to display on your Status Page. Each Service will be visible with it's own status graph, showing it's current status and historical data.
   <Tip> You can add / remove Services via the [`Structure`](/advanced/status-pages#structure-of-status-page) section of your Status Page, anytime. </Tip>
4. Next, select `Create Status Page`.

<img />

### Edit Status Page

Next, you will find the following menu:

1. There are six different tabs to configure your Status Page, [Edit](/advanced/status-pages#edit-status-page), [Structure](/advanced/status-pages#structure-of-status-page), [Hosting](/advanced/status-pages#hosting-of-status-page), [Public Appearance](/advanced/status-pages#public-appearance-of-status-page), [Embed](/advanced/status-pages#embed-status-page) and [Subscribers](/advanced/status-pages#manage-subscribers-of-status-page). In the **Edit** tab, you will find the information you entered to create the Status Page. You can change it anytime.
2. Select the `Timezone` for displaying times on your Status Page. If omitted, the default timezone is UTC.
3. Select how many days of uptime history you want to display for your Services on the Status Page. Select between different timeframes, ranging from last 7 days to the whole last year.
4. `Hide history, graphs, and uptime % on the public page`: Public page shows only current service status—no uptime percentage and no historical bar graphs. Incident history pages (opened by clicking the status graph) are also hidden. The history length above still applies when this option is off.
5. `Hide incident details on the public page`: Hides incident titles, timelines, and public comments on the public page and hides incident history pages. Overall severity indicators remain visible.
6. `Hide maintenances on the public page`: Hides scheduled and ongoing maintenance sections on the public page, and hides history of maintenances on incident history pages.

Don't forget to `Save` your changes.

<Info> As soon as you defined a URL for your Status Page in the [hosting section](/advanced/status-pages#hosting-of-status-page), you will find it in the header.</Info>

<img />

### Structure of Status Page

Next, define how your Status Pages are organized — including how related Services are grouped and ordered on the page.

1. This can be done via the `Structure` tab.
2. In this example, there are two separate Service groups. You can rearrange their order using drag-and-drop.
3. When editing a group, you can set a `Service Group Public Title`. If a title is set, all Services in the group will be collapsed under this heading on the Status Page. If no title is provided, each Service will be displayed individually (see below).
4. You may add a `Service Group Public Description` if a `Service Group Public Title` is set.
5. You can also add, remove and sort Services within one group.
6. Don't forget to save your changes.
7. Example for a Service group with one Service and without `Service Group Public Title`.

Add additional groups using the `+ Add Service Group` button at the buttom of the page.

<img />

Once you’ve activated your Status Page in the [Hosting](/advanced/status-pages#hosting-of-status-page) section, your setup will appear like this on the live page.

1. Service Group **with** `Service Group Public Title` (expanded).
2. Service Group **without** `Service Group Public Title`.

<img />

### Hosting of Status Page

You can either host your Status Pages on our domain or host them on your own custom domain (cname).

#### Hosted on All Quiet

1. Open the `Hosting` tab.
2. Select hosting type `All Quiet`.
3. Select the URL slug for your Status Page.
4. Click `Save Hosting` to save.

<img />

#### Hosted on Your Custom Domain

1. Select `Custom Host (CNAME)`
2. Define the custom host. This will be the URL of your Status Page on your custom domain.
3. You now need to copy and past the names and values for CNAME, Domain Verification and SSL Validation to your DNS provider to verify ownership of the custom host.
4. Afterwards, click `Update Hosting`.
5. Validation takes a few minutes. Until validated, you'll see a yellow label `Waiting for Validation`. Once validated, you'll see a green label `Hostname successfully set up`.

<Note>Depending on your DNS provider and DNS propagation, it can take up to **48 hours** until All Quiet receives verification that the Hostname and SSL validation have been confirmed.</Note>

<img />

#### Access Control & Private Status Page

Use the `Access Control` panel on the `Hosting` tab to transform a public page into a private, access-restricted view.

1. Activate `Disable Public Page`. When enabled, the public HTML will return a 404 error.
2. Activate `Disable Public JSON`. When enabled, the public JSON endpoint will return a 404 error.
3. And an `IP Filter` to restrict access to specific IP addresses or CIDR ranges and make the Status Page private.
4. Activate `User Authentication Required`. When enabled, the page will only be accessible to All Quiet users associated with the Status Page's [organization](/advanced/organizations).
   <Info> `User Authentication Required` is not available for Status Pages hosted on your own custom domain (CNAME).</Info>
5. `Password Protection`: Visitors must enter a password to view this status page, including the public JSON and badge. Everyone with the password can access the page.
   * Password must be **at least 6 characters**
   * Password is **stored encrypted**
   * When changing other access control settings, leave the password blank to **keep the current password**
6. Make sure to `Save Access Control` to apply your changes.

<img />

### Public Appearance of Status Page

Here's how you can configure and change the public appearance of your Status Page.

1. Select the `Appearance` tab.
2. Enter the `Public Title`, shown on your Status Page. If you leave it empty, the Status Page **Display Name** (from creation / the Edit tab) is used as a **fallback in emails and SMS** to subscribers. Set **Public Title** to control the name customers see on the page and in those notifications.
3. Enter a `Public Description`, that will be visible below the `Public Title`
4. Enter a `Public Company Name`, that will be diplayed in header and footer of the Status Page. Moreover, it will be used as the "From" name in the emails to subscribers of your Status Page.
5. You can enter a `Public Company URL`, opened when clicking the `Public Company Name` on your Status Pages.
6. Add a `Public Support URL` for your customers.
7. Your `Public Support Email` will be diplayed on the Status Pages, plus will be used as email address to reply to in Status Page update emails.
8. Optionally, you may define the number of `Decimal Places` that is displayed for your Service's uptime.
9. You may want to create public, less technical titles for our incident severities `Critical`, `Warning` and `Minor`. If omitted, we will use our severities for incidents on the Status Page and in corresponding emails.
10. You can customize the colors of your Status Page and may add extra colors for dark mode. If omitted, we use the same colors for light and dark mode.
11. To save the changes, click `Save`.
12. You can add a `Logo`, `Logo (Dark Mode)` and `Favicon`, visible on the Status Page. Uploads are saved automatically. If you don't upload a Logo for dark mode, we use the same logo for light and dark mode. You can use .png, .jpg or .svg format.

<img />

### Embed Status Page

Select between different options to embed your Status Page on your website. You can simply embed the **Link**, embed the Status Page in an **Iframe**, use our **Badge**, or read the current status via **JSON** and build a custom frontend.

<img />

### Manage Subscribers of Status Page

The `Subscribers` tab allows you to manage and oversee the subscribers of your Status Page.

1. `Disable Public Subscription`: When enabled, users can not subscribe via your Status Page (we remove the `Subscribe` button). New subscribers can only be added via this page.
2. `Enable SMS Subscription`: Available as an add-on in an individual Enterprise deal.
3. To add new subscribers, click `+ Add Subscribers`

<img />

1. Enter the email addresses you want to add as subscribers.
2. Click `Add` to invite email addresses to subscribe.

<img />

1. You will find the invited email addresses in the list.
2. `Confirmed` is empty as long as the owner of the email address hasn't confirmed the subscription. The email address will not receive any Status Page updates until confirmation.
3. You can remove subscribers by clicking the 3-Dot-Menu and choosing `Delete`. Subscribers themselves can always unsubscribe via links in the Status Page update emails or via the Status Page itself (the latter is not possible when `Disable Public Subscription` is active).

<img />

After adding email address as subscribers, the owner of the email address will receive this email.

1. Notice that the [Public Company Name](/advanced/status-pages#edit-status-page) is used as the "From".
2. Owner of the email address needs to confirm the subscription.

<img />

Aftwerwards, you will find the "confirmed" timestamp in the `Subscribers` tab.

<img />

<Check> You have successfully configured your first Status Page! Now, let's have a look what it can do.</Check>

## Your Public Status Page

Next, open your Status Page to see the changes. If you uploaded a favicon, you should see it in your browser tab. If not, delete your cache and try again.

On the page, you will find the following

1. Uploaded `Logo`
2. Your `Public Company Name`. Clicking it will open the `Public Company URL`.
3. In case you added a `Public Support Email`, users will find it here.
4. In case you added a `Public Support URL`, users will find a "Support" link.
5. The `Public Title` of the Status Page.
6. The `Public Description` of the Status Page.
7. The `Subscribe` button, only visible when public subscription is enabled.
8. The current status of the Services listed on the Status Page.
9. **Ongoing incidents** affecting a Service, displayed above that Service's status graph—similar to how [ongoing maintenances](/advanced/status-pages#communication-of-service-maintenances-on-status-pages) are shown.
10. An example of a Service Group with `Public Service Group Title`, collapsed, showing the overall status of the Services within the group.
11. The `Public Title` of a Service without `Public Service Group Title`. Each Service listed on this Status Page will receive it's own status graph.
12. The `Public Description` of the Service.
13. The historic uptime & the current status of the Service.
14. The status graph of the Service. If there's no historic data, the chart elements are coloured grey. Click any interval to open the [incident history](/advanced/status-pages#public-incident-history) for that time period—including [past maintenances](/advanced/status-pages#communication-of-service-maintenances-on-status-pages).

More about sections 9 & 14 in section [Communication of Incidents on Status Pages](/advanced/status-pages#communication-of-incidents-on-status-pages)

<img />

### Communication of Incidents on Status Pages

This section is designed to explain how incidents and incident updates are displayed on Status Pages. Moreover, we will add more context about the emails that your Status Pages' subscribers will receive.

#### Status Graph

The status graph of each Service on your Status Page shows both, historical and real-time information about the status of the Service.

1. The historical information can be retained from the color codes of the time intervals.
   1. **Green** = Service operational, no incidents that affected the Services.
   2. **Blue** = At least on incident with `Minor` severity during this interval.
   3. **Yellow** = At least on incident with `Warning` severity during this interval.
   4. **Red** = At least on incident with `Critical` severity during this interval.
   5. **Grey** = no data available
2. You can also see the current state of the Service (here: operational) and the historic uptime for the considered history. By default, affecting incidents of all severities lower the uptime—it is the percentage of incident-free time. If [**Affects Uptime**](/essentials/incident#affects-services) is **disabled** for an incident, it can still appear on the Status Page but does **not** count toward downtime or reduce the uptime percentage. See [Affects Uptime on Status Pages](/advanced/status-pages#affects-uptime) below.
3. **Click any interval** on the graph to open the [incident history](/advanced/status-pages#public-incident-history) for that time period—all incidents that affected the Service during the interval, plus any [past maintenances](/advanced/status-pages#communication-of-service-maintenances-on-status-pages) that overlap with it.

<img />

<h4>
  Affects Uptime on Status Pages
</h4>

When an incident [affects](/essentials/incident#affects-services) a Service, **Affects Uptime** controls whether that incident counts toward **downtime** and the displayed **uptime percentage**:

* **Enabled** (default): The incident is included in downtime calculations and lowers historic uptime, and the status graph reflects the incident severity for the affected intervals.
* **Disabled**: The incident does **not** count as downtime and does not reduce uptime. It can still appear on the Status Page (including in incident history pages) and affect the current service status when open.

**Affects Uptime** is enabled by default when you [manually create](/essentials/incident#manually-create-an-incident) or [**Affect**](/essentials/incident#affects-services) an incident. To change it, use the create or affect overlay in the Web App—see the [incident guide](/essentials/incident#affects-services).

<img />

#### Public Incident History

**Ongoing incidents** are displayed above the affected Services' status graphs. **Upcoming** and **ongoing** [maintenances](/advanced/status-pages#maintenances-of-Services) follow the layout described in [Communication of Service Maintenances on Status Pages](/advanced/status-pages#communication-of-service-maintenances-on-status-pages).

To view past incidents, **click an interval** on a Service's status graph. This opens an **incident history page** for that time period, listing all incidents that affected the Service—and any overlapping **past maintenances**.

1. It depicts the service's status during the considered time period.
2. It lists all maintenances that overlapped with the considered time period (if history graphs are enabled and `Hide maintenances on the public page` is disabled).
3. It lists all incidents that affected the Service during the considered time period, including all public comments and details that lead to the resolution of the incident (if history graphs are enabled and `Hide incident details on the public page` is disabled).
4. It includes a link back to the status page.

<img />

Public incident history is limited to **30 incidents per calendar day** (using the Status Page [timezone](/advanced/status-pages#edit-status-page)). When more than 30 incidents apply to a single day, the page shows 30 and a line: **"N additional incidents not shown."** (where **N** is how many incidents for that day are not listed).

#### Example - Incident Affects Service

To see what happens when an incident affects a Service, we can best look at an example.

<Steps>
  <Step title="Incident Overview - Incident Affects Service">
    We know that an incident affects one of our Services. So we select the [affect](/essentials/incident#affects-services) action.

    1. In the overlay, we select the affected Service.
    2. [**Affects Uptime**](/essentials/incident#affects-uptime) is enabled by default—disable it if you want subscribers to see the incident without it counting toward [downtime](/advanced/status-pages#affects-uptime).
    3. Next, we can add a comment. If previously created, we can make use of our [Service Message Templates](/advanced/status-pages#add-message-templates-to-Service), here.
    4. When an incident affects a Service, we will inform the subscribers of your Status Page in any case. You can decide if you want to share a public comment with them, too.
    5. To finish the action, click `Save`.

    <img />
  </Step>

  <Step title="Incident Action with Public Comment">
    Here, we added the message template to the incident and [published the comment](/essentials/incident#action-with-comment).

    <img />
  </Step>

  <Step title="Active Incident on Status Page">
    On the status page, the ongoing incident is reflected as follows:

    1. The summary section shows there's and incident ongoing (1).
    2. You can see the ongoing incident on the Status Page, displayed **above** the Service's status graph. As the incident is of critical severity and we [mapped it](/advanced/status-pages#public-appearance-of-status-page) to the public name **Major Outage**, this is what status page subscribers will see.
    3. The ongoing incident's history is displayed, including the public comment and the related action.
    4. The status graph shows that the Service is currently not operational, and the latest time interval is filled red.

    <img />
  </Step>

  <Step title="Subscribers receive update per Mail">
    Status Page subscribers receive an update about the new incident per email, including the public comment and the related action.

    <img />
  </Step>

  <Step title="Incident is resolved">
    Next, the incident is resolved. Subscribers receive an update about the resolved incident per email, including the public comment and the related action.

    <img />
  </Step>

  <Step title="Status Page - Service is operational">
    After the resolution, the status page reflects that the incident has ended.

    1. The ongoing incident section above the graph is cleared. If there are no open incidents affecting this or other Services, the Status Page now correctly displays all Services as operational.
    2. The status graph demonstrates that the Service is operational again. The affected interval remains red.
    3. Click that interval to view the resolved incident in the [incident history](/advanced/status-pages#public-incident-history) for that period.

    <img />

    The resolved incident is now reflected in the public incident history page for that period.

    <img />
  </Step>
</Steps>

#### List of Incident Actions that Update The Status Page

Below you can find a table that shows which [incident actions](/essentials/incident#quick-actions) are shared publicly on the Status Pages.

**Each action that is shared publicly is also shared per email with subscribers**.

| Incident Action | Shared Publicly?                                                                                | Implication if Shared Publicly?                                                        |
| :-------------- | :---------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------- |
| `Affects`       | Yes. Additional public comment is optional.                                                     | Incident is added to Status Page, Services are affected.                               |
| `Resolve`       | Automatically, if incident affects a Service. Additional public comment is optional.            | Affected Services are operational, again. Public comment is added to incident history. |
| `Investigate`   | Only if incident affects a Service + a public comment is created with the `Investigate` action. | Public comment + `Investigate` action are added to the incident history.               |
| `Escalate`      | Only if incident affects a Service + a public comment is created with the `Escalate` action.    | Public comment + `Escalate` action are added to the incident history.                  |
| `Comment`       | Only if incident affects a Service + comment is made public.                                    | Public comment is added to incident history.                                           |
| `Reopen`        | Automatically, if incident affects a Service. Additional public comment is optional.            | Incident is reopened on Status Page, Services are affected, again.                     |

## Maintenances of Services

<Info>*Organization Owners*, *Organization Administrators* and  *Organization Members* have the permissions to create and edit maintenances for the Services.</Info>

Maintenances are a necessity. To keep your customers in the loop, we've a added a `Maintenance` feature for status ages, allowing you to inform customers about plannend maintenances in advance, as well as keeping them in the loop during a maintenance.

<Note> Incidents that occur during a maintenance and [affect](/essentials/incident#affects-services) a Service will not be visible on Status Pages and not count as downtime. To keep an incident visible but exclude it from uptime calculations outside of maintenance, disable [**Affects Uptime**](/essentials/incident#affects-services) on the incident instead—see [Affects Uptime on Status Pages](/advanced/status-pages#affects-uptime).</Note>

### Create Maintenance for Services

To be able to create a maintenance, you first need to [create a Service](/advanced/status-pages#create-a-Service).

1. Then, select `Service Maintenances‚` in the Web App.
2. Click `+ Create`.

<img />

1. Create an internal `Display Name` for the Maintenance. It won't be shared publicly.
2. Select the `Organization` of the maintenance. Only Services belonging to this organization can be selected for maintenance.
3. Select the `Services` affected by the maintenance.
4. To save, click `Create Maintenance`.

<img />

Next, you can plan the maintenance.

1. Select the maintenance's timezone.
2. Schedule the maintenance.
3. Add a `Public Description` for the maintenance, visible on your Status Pages that feature the affected Service(s) and in the update emails for your status page's subscribers.

Don't forget to `save` your settings.

<img />

On `/app/Service-maintenance` in the Web App, you can see all your maintenances. From here, you can edit and delete them.
<Warning>Caution: Don't delete past maintenances. They will vanish from incident history pages (and no longer appear when clicking the status graph), and incidents that occured during the deleted maintenance will count as downtime for the affected Services. Rescheduling a past maintenance for the future has the same effect. Instead, we recommend to create a new maintenance and copy the content from the past to the new maintenance.</Warning>

<img />

### Communication of Service Maintenances on Status Pages

In general, Service maintenances are communicated via two channels

* They are displayed on the Status Pages that feature the Services in maintenance
* There are emails informing subscribers of Status Pages about the Service maintenances. You can find an [email list](/advanced/status-pages#emails-for-maintenances) at bottom of the page for more information.

On the Status Pages, an **Upcoming Maintenance** for a Service is displayed directly below the status graphs.

<img />

For **Ongoing Maintenances**:

1. There is be a banner on top of the Status Page, even above the status graphs.
2. The status graphs of the Services in maintenance show the maintenance icon.

<img />

To find **Past Maintenances**, click the corresponding interval on the Service's status graph—the [incident history](/advanced/status-pages#public-incident-history) for that period also lists maintenances that overlapped with it.

<img />

#### Emails for Maintenances

Below you can find a list of emails that are sent out to subscribers in context of Service maintenances.

| Email Copy                            | Email Headline          | Trigger                                                                                  |
| :------------------------------------ | :---------------------- | :--------------------------------------------------------------------------------------- |
| `Maintenance scheduled for "Service"` | `Maintenance Scheduled` | The schedule of the maintenance is created or changed. Not sent for ad-hoc maintenances. |
| `Maintenance started for "Service"`   | `Maintenance Started`   | The maintenance starts.                                                                  |
| `Maintenance ended for "Service"`     | `Maintenance Ended`     | The maintenance has ended.                                                               |
| `Maintenance cancelled for "Service"` | `Maintenance Cancelled` | The maintenance has been deleted.                                                        |

**Email Body**

The body of the email is always the same, only copy and headline change. It always features the `Public Description` of the maintenance.
Below, you can find an example.

<img />


# Terraform Provider
Source: https://docs.allquiet.app/advanced/terraform

<Note>Terraform is available on Pro and Enterprise plans.</Note> Terraform is an Infrastructure as Code (IaC) tool. After setting up our Terraform provider, you can manage All Quiet via your Infrastructure.

## Set up All Quiet Terraform Provider

Open the latest version of the [All Quiet Terraform Provider](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest).

1. Click on `Use Provider`.
2. Copy the code and paste it into your terraform configuration file. If you haven't set up a terraform file yet, follow the instructions on [Terraform's website](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli).
3. Run `terraform init` in your terminal.

<img />

To use our Terraform provider, you need to create an API Key, next.

### Create API Key

<Note>Creating an API Key requires you to be the Owner or Administrator of an Organization. To set up an Organization, please follow the related [documentation](/advanced/organizations). </Note>
<Warning>The account that creates the Organization cannot be provisioned via Terraform. Therefore, we recommend to create the Organization with a root user that is not bound to a specific employee, like [admin@allquiet.app](mailto:admin@allquiet.app). This way, you ensure all "real" on-call users and employee accounts can be provisioned.
If you already set up the Org with your personal account, you can change your account's email address via the Web app on /app/account to a root user email and later provision your personal email and account via Terraform.</Warning>

Open our [All Quiet Terraform Provider Documentation](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs).

1. Copy the code snippet and paste it into your configuration file.
2. In the file, set your `api_region` depending on your organization's data storage region.
3. Next, you need to generate "your\_api\_key".

<img />

Generating the API key has to be done in the [All Quiet Web App](https://allquiet.app/app/organizations). Afterwards, you can set up everything via our Terraform Provider.

1. In the Web App, open `Organizations`.
2. Select the correct Organization and click `API Keys`

<img />

Click `+Create API Key`

<img />

1. Add a `Display Name` for your API Key.
2. Approve the API Key creation by clicking `Yes, Create`.

<img />

Now, copy the generated API Key...

<img />

...and paste it into your configuration file

<img />

<Check>Congrats, your good to go and can use All Quiet via Terraform!</Check>

### All Quiet Resources in Terraform

Please find the documentation of our resources attached.

* [allquiet\_user](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/user)
  * <Warning> When provisioning users and you want them use OIDC, Google or Microsoft login, we first need to setup [OIDC](/miscellaneous/sso#openid-connect-oidc) before they can log in. If you want them to use password login on All Quiet, this will work out of the box.</Warning>
* [allquiet\_user\_incident\_notification\_settings](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/user_incident_notification_settings)
  * <Info>Since Terraform Provider `v3.0.0`, incident notification settings are managed via this dedicated resource. It replaces `incident_notification_settings` previously configured inside the `allquiet_user` resource.</Info>
* [allquiet\_team](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/team)
* [allquiet\_team\_memberships](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/team_membership)
* [allquiet\_team\_escalations](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/team_escalations)
* [allquiet\_on\_call\_override](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/on_call_override)
* [allquiet\_integration](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/integration)
* [allquiet\_integration\_mapping](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/integration_mapping)
  * If you don't use this resource, your integrations will implicitly follow our default mappings. If you want to adjust the mapping, we've prepared template `allquiet_integration_mapping`.
    * Template Download (Example with Integration\_ID = "Datadog"): [https://allquiet.app/api/integrations/terraform/default/Datadog.tf](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](https://allquiet.app/api/public/v1/inbound-integration/types)
* [allquiet\_integration\_maintenance\_window](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/integration_maintenance_window)
* [allquiet\_outbound\_integration](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/outbound_integration)
* [allquiet\_routing](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/routing)
* [allquiet\_organization\_membership](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/organization_membership)
  * <Info> There's no `allquiet_organization` resource as the [API Key](/advanced/terraform#create-api-key) you use for your Terraform config is always bound to a specific organization. All `allquiet_organization_membership` resources are bound to this organization</Info>
* [allquiet\_service](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/service)
* [allquiet\_status\_page](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/status_page)

<Tip>To learn more about Terraform commands, please check their [tutorials](https://developer.hashicorp.com/terraform/tutorials).</Tip>

#### Provisioned Resources Cannot Be Edited Via Web App

To ensure that the resources managed by your Terraform provider stay in sync with your setup, we lock provisioned resources within the Web App. This means these resources cannot be edited or deleted directly through the Web App's interface.

Provisioned resources are marked with an icon, and hovering over it will display a message explaining why the resource is locked and cannot be modified via the Web App.

<img />

Our Terraform provider is designed to help you configure and manage your standard setup seamlessly. However, temporary changes — such as on-call schedule overrides or maintenance windows — will always be able to be added via the Web's interface.

#### Find Provisioned Users in All Quiet

To see the users currently provisioned via Terraform in All Quiet,

1. Select your [Organization](/advanced/organizations)
2. Open the `Associated Users` tab. Here, you can see all users of your organization.
3. Users provisioned via Terraform can be identified by `Source` = TF

<Info>If you provision the phone numbers of your users via Terraform, they still have to confirm their phone number via [notification settings](/essentials/channels#sms-and-phone-calls).</Info>

<img />


# Alerting Channels
Source: https://docs.allquiet.app/essentials/channels

Never miss an incident again

## Stay Informed, Always

All Quiet ensures you're always in the loop with a variety of alerting channels, keeping your team alert and ready to respond:

* Emails
* Push Notifications
* SMS
* Voice Calls

Enhance your alerting framework by integrating All Quiet with your favorite tools, such as [Slack](/integrations/outbound/slack), through our [outbound integrations](/essentials/outbound). For more intricate workflows, like avoiding phone/SMS alerts for incidents with attributes like `ENV = Test`, consider leveraging our [advanced incident routing capabilities](/advanced/routing).

## Prioritize with Severity Levels

All Quiet categorizes incidents into three severity levels, helping you prioritize your response effectively:

* `Critical`: Immediate action required. Major impact with urgent attention needed.
* `Warning`: Potential for escalation. Address promptly to prevent negative effects.
* `Minor`: Non-urgent & low impact. Schedule resolution at your convenience.

Tailor incident severities via the [payload mapping](/essentials/inbound) settings in your inbound integrations.

## Customizable Notification Preferences

To tailor our alerting to your needs, you can customize your settings under [`Your Account` > `Notifications`](https://allquiet.app/app/account/notifications) (1).

Here, you can

* download the native All Quiet App to receive push notifications (2)
* [add your phone number](/essentials/channels#sms-and-phone-calls) to activate voice & SMS notifications (3)
* and manage settings for the different notifications [channels](/essentials/channels#channels) (4).

<img />

<Note>Notification Preferences for Terraform-provisioned Users have to be provided via [Terraform Ressource](/advanced/terraform#all-quiet-resources-in-terraform) [allquiet\_user](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/user).</Note>

### Channels

Select between and combine the following personal notification channels.

* **Emails** (to activate, first confirm your email address)
* **Push Notifications** (to activate, first download the App and login)
* **SMS** (follow instructions [below](/essentials/channels#sms-and-phone-calls) to activate)
* **Voice Calls** (follow instructions [below](/essentials/channels#sms-and-phone-calls) to activate)

You can enable and disable each channel seperately under `Notification Channels`.

<img />

### Smart Notification Delays

In the same section you can also enable smart notification delays for each channel.

<img />

Minimize disruptions by setting delays (0 to 60 minutes) on certain notifications. If an incident is unresolved or unattended within this timeframe, you'll be alerted after the delay, ensuring notifications are meaningful and necessary. Our goal is to maintain all quiet, as we believe calm teams are productive teams.

### Alert Severities

Alerts are tailored by default based on incident severity to ensure efficient notification:

* **Critical Incidents:** all channels - Emails, Push Notifications, SMS, and Phone Calls.
* **Warning Incidents:** Emails, Push Notifications, and SMS.
* **Minor Incidents:** via Emails and Push Notifications only.

In the `Notification Preferences` section, you can customize these settings for each severity (1) and notification channel (2) anytime.

<img />

### Notifications per Action

You can active and deactivate each notification channel for certain incident actions, e.g. you can decide to receive an email for the "Forwarded" action but deactivate push notifications for this kind of action.

In the `Notification Preferences` section, you can customize these settings for each action (1) and notification channel (2) anytime.

<img />

## SMS and Phone Calls

Ensure you're promptly informed of every incident through SMS and voice calls by following these easy steps:

### Enable SMS and Voice Messages

<Steps>
  <Step title="Step 1: Navigating to 'Notifications' under Your Profile">
    Start by accessing your personal notification settings. From the main dashboard, click on your Username in the top left corner. In the drop down, select `Notifications`.
  </Step>

  <Step title="Step 2: Entering Your Phone Number">
    Note, that you can only confirm your phone number after confirming your email addreess.

    1. In the 'Phone Number' field, input your number using the international format. For instance, you might enter: +491735311461.
    2. After entering, you will be asked to request a confirmation code. You can request the Code via SMS or Voice Call.
    3. After receiving the confirmation code. enter the code and "confirm" your phone number

    <img />
  </Step>

  <Step title="Step 3: Activating SMS & Voice channels">
    Navigate to the [`Notifications Channels`](/essentials/channels#channels) section on the same page.

    * For SMS Notifications: Make sure the toggle for `SMS` is enabled if you wish to receive SMS updates on incidents.
    * For Phone Calls: Make sure the toggle for `Voice Call` is enabled if you wish to receive SMS updates on incidents.
    * For both, Voice Calls and SMS: You may want to add [smart notification delays](/essentials/channels#smart-notification-delays) to adjust the notifications to your way of working.
  </Step>

  <Step title="Step 4: Select Severities and Actions for SMS & Voice Call Updates">
    In the `Notification Preferences` section, you can select the [severities](/essentials/channels#alert-severities) and [incident actions](/essentials/channels#notifications-per-action) for which you'd like to receive anytime.
  </Step>
</Steps>

### Our Phone Numbers

<Note>Phone calls are triggered only once, at the moment an incident is opened, assigned or escalated.
Per default,Calls are reserved for incidents marked with the severity level of "Critical". You can adjust these setting. </Note>
We'll always call you from fixed numbers. To recognize All Quiet calls more easily, add our contact card to your address book: [download the All Quiet contact card](https://allquiet.app/allquiet-contacts.vcf) or scan the [All Quiet contacts QR code](https://allquiet.app/allquiet-contacts-qr.svg).

<Info>Enterprise customers may have other, additional phone numbers. Reach out to your admin or [support@allquiet.app](mailto:support@allquiet.app) to learn more.</Info>

### SMS and Voice Rate Limits

<Info>Our current rate limits to protect the functionality of the platform for all customers.</Info>

**Default rate limits:**

* **SMS**:  1 SMS per unique phone number, 8 SMS per unique phone number within 1 minute
* **Phone Calls / Voice Messages**: 1 Call per unique phone number within 1 second, 8 Calls per unique phone number within 1 minute

<Info>To prevent abuse, we may apply country specific rate limits. To learn more about our rate limits or if your organization needs specific rate limits reach out to [support@allquiet.app](mailto:support@allquiet.app)</Info>

## Native App Push Notifications

Push notifications in All Quiet are designed to keep you informed about incidents, whether they're minor updates or urgent emergencies. **Of course, notifications will only be sent once you have granted the necessary permissions on your device.** Here's how notifications work on both iOS and Android:

### iOS

<Note>From version 1.22.0</Note>

**Normal Notifications:**\
By default, All Quiet sends push notifications for all incident updates. These notifications respect your device's sound and focus settings - if your phone is on silent or in a Focus mode, you may not hear a sound, but you'll still see the notification banner.\
<Info>Normal notifications use your iPhone's system notification volume.</Info>

#### Critical Alerts

For incidents marked as "Critical," you can enable "Critical Alerts" in the app. When enabled, these notifications will break through silent and focus modes, ensuring you never miss an urgent alert. You can control this permission in your iOS settings.\
<Info>Critical Alerts will only be triggered when the incident's severity is <code>Critical</code>. This feature allows All Quiet notifications to break through silent and "Do Not Disturb" modes. <br /> When enabled, critical alerts use the volume you set in the All Quiet app's settings screen, not the system volume.</Info>

<Steps>
  <Step title="Granting Push Notification Permissions">
    After logging in for the first time, users are encouraged to authorize push notifications. Users also have the option to activate "Critical Alerts". Upon selecting this checkbox, the iOS system will prompt for the necessary permissions, as depicted in the subsequent screen.

    <img />
  </Step>

  <Step title="Allowing 'Critical Alerts'">
    The screenshot depicts the operating system's request for permission to enable critical alerts.

    <img />

    In the All Quiet App's settings, you can see the current state of your notification permissions. You can always change your permissions, anytime.

    <img />
  </Step>
</Steps>

#### Do Not Disturb (DnD) & Other Focus Modes

Normal notifications will not make a sound if DnD or Focus is enabled, but critical alerts (if allowed) will always get through with sound and vibration, even if your phone is muted.\
<Info>When DnD or Focus is enabled, only critical alerts (if allowed) will play a sound, using the app's critical alert volume setting.</Info>

### Android

<Note>From version 1.20.0</Note>

**Normal Notifications:**\
All Quiet sends push notifications for all incident updates. These notifications follow your device's standard notification settings—if your phone is on silent or DnD, you may not hear a sound, but you'll still receive the notification. You can fine tune your notification preferences in the "Notification Channel Settings" for the All Quiet Incident Channel, under "Settings".
<Info>Normal notifications use your Android device's **system notification volume**. When receiving a notification while playing media or in a call, we adapt the volume to the **media / the voice call volume.**</Info>

#### Critical Alerts

All Quiet for Android gives you fine-grained control over how critical alerts behave, even when your phone is muted or in Do Not Disturb (DnD) mode.

* There are two separate toggles in the app's notification settings:

  1. **Override System Volume (When DnD is off):** When notifications are allowed, enabled by default. When this is on, critical alerts will play a sound even if your phone is in silent mode (but not in DnD). You can set a custom volume for these alerts in your notification settings. When receiving a notification while playing media or in a call, we adapt this volume to the **media / the voice call volume**.
  2. **Override Do Not Disturb (DnD):** Must be opted-in. When enabled, critical alerts will play a sound even if your phone is in DnD mode. This also has its own volume setting (see [DnD section below](/essentials/channels#do-not-disturb-dnd) for more details). When receiving a notification while playing media or in a call, we adapt this volume to the **media / the voice call volume**, too.

<img />

* Both toggles allow you to set the alert volume independently from your device's system volume.
* You can always adjust these settings in the All Quiet app under notification preferences.

<Info>Critical alerts will only break through silent or DnD modes if the corresponding toggle is enabled. The sound volume for each scenario is determined by the app's settings, not your device's system volume.</Info>

#### Do Not Disturb (DnD)

Normal notifications will be silenced by DND, but critical notifications (if DND override is enabled) will break through and alert you with sound and vibration.\
<Info>When DND is enabled, only critical alerts (if allowed) will play a sound, using the app's **DnD override alert volume setting**. When receiving a notification while playing media or in a call, we adapt the volume to the **media / the voice call volume.**</Info>

Here's how to enable DnD override in your app.

<Steps>
  <Step title="Do Not Disturb (DnD) Volume Override for Critical Alerts">
    The first screenshot shows our notification settings after enabling normal notifications. Users are introduced to the option of overriding the "Do not disturb" (DnD) mode. To override the DnD mode, you need to grant the app permission to override system DnD settings. The system settings can be opened by clicking the chevron next to "Override DnD Volume".

    <img />
  </Step>

  <Step title="Overriding 'Do Not Disturb' Mode in System Settings">
    You're forwarded to the Android system settings for Do not Disturb. Make sure to allow "App notifications" for All Quiet.

    <img />

    Please note that some Android devices may have slightly varied menus or terms depending on the manufacturer and version of the Android OS. Always refer to your device's user manual or official support channels if you're uncertain about any step.
  </Step>

  <Step title="DnD Override Successfully Activated">
    Returning to the Notification settings screen, you can see that the DnD override is now activated. You can adapt the volume to your preference. If needed, you can also disable the DnD override from here.

    <img />
  </Step>
</Steps>

## Personal Notification Logs

Personal Notification Logs let each user see a **history of notifications sent to them** (email, SMS, voice calls, push), including the **delivery outcome** and relevant context (sender/provider, incident link, and errors when applicable).

In the web app, open the **Account** dropdown.

1. Open **Notifications**
2. Open **Notification Logs** tab (`/app/account/notifications/history`).

This view continuously refreshes while you’re active, so you can watch outcomes update in near real time.

<img />

### What’s Shown per Log Entry

Each row includes:

* **Time** of the entry (with a tooltip showing when the log entry expires)
* **Channel icon** (Email / SMS / Voice Call / Push)
* **Recipient** (e.g. masked email address / masked phone number; or `—` if unavailable)
* **Result** (see [glossary below](/essentials/channels#notification-result-glossary); errors are shown inline when present)
* **From** (our customer-facing sender label, when available)
* **Action** (the incident action that triggered the notification)
* **Action Time** (the timestamp of the action that triggered the notification)
* **Incident** (a link to the incident if the notification was incident-related)

<h3>
  Retention & Availability
</h3>

* **Retention**: notification logs are retained for **30 days** (as displayed in UI).

<Note>On **Enterprise** plans, retention may differ if your organization agreed on a custom period — contact [support@allquiet.app](mailto:support@allquiet.app).</Note>

<span />

### Notification Result Glossary

The UI maps internal result codes to user-facing labels. These are the outcomes users will see:

* **Sent** (`Succeeded`): Our system successfully sent the notification to the recipient. If the recipient still did not receive the notification, it is likely due to carrier, internet or provider issues.
* **Delayed** (`Delayed`): The notification is intentionally postponed. If known, the UI shows the delay (e.g. “Delayed (5 min)”).
* **Discarded** (`Discarded`): A previously scheduled notification was **not sent** because it no longer applied. This happens if there's a newer action on the incident that no longer requires a notification for the action that initially triggered the notification.
* **Rate limited** (`RateLimited`): Sending was throttled by a provider or system rate limit.
* **Invalid recipient** (`RecipientInvalid`): Recipient address/number is invalid.
* **Blocked recipient** (`RecipientBlocked`): Recipient is blocked (policy/provider/user-level).
* **Recipient not supported** (`RecipientNotSupported`): The recipient can’t be used with that channel/provider.
* **Failed** (`Failed`): A send attempt failed (details may be shown as error text).

## Troubleshooting: no personal channel alerts (email, SMS, push, voice)

<span />

If an incident exists but you get **no email, push, SMS, or voice** on your personal channels, start by checking whether All Quiet attempted to notify you.

### 1) Check your Personal Notification Logs

Open **Account → Notifications → Notification Logs** (`/app/account/notifications/history`) and look for an entry around the incident action time.

* **If there is a log entry**: use the **Result** to understand what happened (for example **Delayed**, **Discarded**, **Rate limited**, **Invalid recipient**, **Failed**). Errors (when available) are shown inline in the log entry. See the **[result glossary](/essentials/channels#notification-result-glossary)**.
* **If there is no log entry**: the system likely never attempted to notify you for that action (for example because routing muted the channel, you are not part of the notified audience for that incident/team, or your personal notification preferences disabled that channel/action).

If you are a **team admin** (or have the relevant org permissions), you can also inspect the incident’s **Notification History** overlay to audit delivery for the whole incident and all users.

### 2) Check routing & personal preferences

If the logs show **no attempt**, or the attempt was **discarded/muted**, **[advanced routing](/advanced/routing)** may be **muting** those paths for incidents that match the rule:

* Find rules whose **conditions match** the incident, then open **[Choose Channels](/advanced/routing#choos-channels)** and look for **Mute all Channels** or a **subset** of channels only (for example SMS or voice excluded).
* Open **[Configure Actions](/advanced/routing#configure-actions)** and check **`Discard`**, **snooze**, and other actions that affect alerting.

Also confirm your own **[notification preferences](#customizable-notification-preferences)** ([severities](/essentials/channels#alert-severities), [per-action](/essentials/channels#notifications-per-action), and channel toggles)—routing applies **on top of** those personal settings.

See **[Inbound — New incident, no notification](/essentials/inbound#inbound-troubleshooting-no-notification)** for a single walkthrough that covers routing together with integration and team **mute** / **snooze**.


# Escalations, Schedules & Rotations
Source: https://docs.allquiet.app/essentials/escalations

Set up reliable on-call rotations with smart escalation policies

With All Quiet, setting up on-call schedules, escalations, and rotations is straightforward. Our user-friendly interface removes complexity, guiding you smoothly through creating a workflow that keeps your team alert and responsive while accounting for different time zones and personal overrides.

Here are three common use cases illustrating how teams on All Quiet typically set up their on-call rotations:

<Tabs>
  <Tab title="Follow-the-sun">
    Follow-the-sun rotations enable global teams, especially those distributed worldwide, to leverage time zone differences for around-the-clock coverage. This ensures on-call duties are always managed during the local daytime hours of team members, enhancing responsiveness and minimizing overnight work.

    * **Setup**: Depending on where your team is located, you can set up two (or more) schedules for the same escalation tier within All Quiet. Team members are then assigned to these schedules, with the option to add rotations. Ideally, this setup ensures every team member only works during their local daytime hours.
    * **Why**: This method leverages time zone differences, minimizing response times to incidents during off-hours in any given region.
    * **Benefit**:  Teams experience less burnout and maintain a higher level of alertness and productivity, as members respond to incidents during their daytime hours.
  </Tab>

  <Tab title="Weekend shifts">
    Weekend shifts ensure continuous coverage while respecting work-life balance by rotating weekend duties among team members. Here's how it works:

    * **Setup**: Within All Quiet, weekend schedules are defined separately, with members assigned to weekend rotations that recur every few weeks. For a single on-call through the weekend with a Monday-morning handoff, see [Weekend on-call through Monday morning](/essentials/escalations#weekend-on-call-through-monday-morning).
    * **Why**: To distribute the responsibility of weekend work evenly across the team, preventing burnout and keeping morale high.
    * **Benefit**: Members know in advance when their weekend shifts will occur, allowing for better personal planning and downtime during their off weekends.
  </Tab>

  <Tab title="Night shifts">
    Night shifts cover the critical after-hours period, ensuring that incidents are addressed promptly, even during the quietest hours. Setting up night shifts involves:

    * **Setup**: Schedules in All Quiet are configured to define night-time periods, often with additional compensation or time-off incentives for these less-desirable hours.
    * **Why**: To maintain operational integrity 24/7 by having a dedicated team ready to respond to incidents that occur outside of regular working hours.
    * **Benefit**: Teams can rest assured that their services remain uninterrupted overnight, with a fresh, alert team handling any issues that arise.
  </Tab>
</Tabs>

<Tip>If you want to skip the definitions, you can check out a hands-on [example](/essentials/escalations#example-setting-up-an-on-call-rotation) at the end of this page that guides you step-by-step through the setup.</Tip>

### Accessing Escalation Policies

To access the escalation management page, simply select the `Escalations` option for the respective team.

<img />

## Escalation Tiers

Escalation tiers allow incidents to be escalated to the next level when they are not acknowledged / resolved by the members of the current tier or when a [manual escalation](/essentials/incident#quick-actions) is triggered. They also allow you to repeat escalations for users that got already alerted.

Check out our [example below](/essentials/escalations#example-setting-up-an-on-call-rotation) for a hands-on use case of setting up various escalation tiers.

### Repeat Escalation Tier

If you want re-alert the on-call members of one tier in case they did not acknowledge / resolve an incident, you can use our `repeat escalation tier` function.
To add a repetition for a specific tier, simply click the label below the tier.

<img />

In the overlay, you can set up you repetition rules for the selected tier.

1. To activate `Repeat current escalation tier`, activate the toggle.
2. Decide when auto-repeat should stop, whether it's after someone [acknowledges](/essentials/incident#history-acknowledged) the incident or whether auto-repeats should happen until someone `Resolves` the incident.
3. Select how often you want to repeat the tier.
4. Select how long you want to wait in between each repetition.
5. Save your settings.

<img />

In this example, after the initial alert to Tier 1, we chose to repeat the notification twice, with a 5-minute gap between each repetition. This means the alert sequence will be:

* Tier 1 alert at t=0 min
* First repetition at t=5 min (if no one acknowledged)
* Second repetition at t=10 min (if no one acknowledged)

If enabled — and if no one in Tier 1 acknowledges / resolves the incident — [auto-escalations](/essentials/escalations#automatic-escalation) to Tier 2 will follow.

### Automatic Escalation

To enable auto-escalations, you first need to add at least a second escalation tier. Without it, the incident will remain within Tier 1, and no further escalation will occur.

Click `+ Add Escalation Tier` and select team members to create the second tier.

<img />

Next, to activate the auto-escalations between two tiers, click on the label that says `Then, doesn't auto-escalate` by default.

The [`repeat`](/essentials/escalations#repeat-escalation-tier) and `auto-escalate` features can, of course, be combined. This allows you to notify Tier 1 multiple times before automatically escalating the incident if no one acknowledges / resolves it.

<img />

In the overlay, you can set up you auto-escalation rules between the selected tiers.

1. To activate `Auto-escalate to next tier`, activate the toggle.
2. Select how long you want to wait after the last scheduled alert in Tier 1 before you auto-escalate to Tier 2. "Last scheduled alert in Tier 1" hereby includes all [scheduled repetitions of Tier 1](/essentials/escalations#repeat-escalation-tier), not only those that actually took place.
3. Decide when auto-escalations should stop, whether it's after someone [acknowledges](/essentials/incident#history-acknowledged) the incident or whether auto-escations should happen until someone `Resolves` the incident.
4. Select which incident severities you want to auto-escalate. Here, we decided to only auto-escalate Critical incidents.
5. You may add `Time Filters`. If added, auto-escalation only take place in the selected times. In the example below, we opted for auto-escalations that happen only during weekdays from 8:00 AM to 7:00 PM.
6. Click `Save` to activate auto-escalations.

<img />

### Auto-Escalations Across Several Teams

<Note>Auto-assign and [manual incident reassignment](/essentials/incident#assign) are supported only within [Organizations](/advanced/organizations) on Pro and Enterprise plans.</Note>

You want to auto-assign an incident to an additional team?
To activate auto-assign, click on the same label that shows your current [auto-escalation settings](/essentials/escalations#automatic-escalation).

<img />

In the overlay, you can set up you auto-assign rules between the selected teams.

1. As you can see, this is the same overlay you would use to activate auto-escalation.
2. To activate `Auto-assign to selected teams`, activate the respective toggle.
3. Select how long you want to wait after the last scheduled alert in Tier 1 before you auto-assign to the selected teams. "Last scheduled alert in Tier 1" hereby all [scheduled repetitions of Tier 1](/essentials/escalations#repeat-escalation-tier), not only those that actually took place. Note that the same cadence is used for auto-escalations, if activated.
4. Decide when auto-assign should stop, whether it's after someone [acknowledges](/essentials/incident#history-acknowledged) the incident or whether auto-assign should happen until someone `Resolves` the incident. Note that the same rule is used for auto-escalations, if activated.
5. Select which incident severities you want to auto-assign. Here, we decided to only auto-assign Critical incidents.
6. Select if you want to notify all assigned users and teams about the **assign** action or if you only want to notify users that are newly assigned.
7. Select the teams you want to auto-assign to. In case you don't select the current team (like in the example), we show a little warning.
8. You may add `Time Filters`. If added, auto-assign only take place in the selected times. In the example below, we opted for to only auto-assign on Saturdays and Sundays.
9. Click `Save` to activate auto-assign.

<img />

<Note>Need to involve more people? The "assign" action can also be used manually when collaborating on incident resolution. Learn [more](/essentials/incident#assign).</Note>

#### Impact on Auto-Escalations

As the incident is reassigned to a different team or the primary team asks additional people to help, the **Assign** action **starts auto-escalations in the newly assigned team(s)**. If the incident is assigned to more than one team, auto-escalations are synchronized between those teams and only stop once an action that marks the incident as acknowleged follows after the **Assign** action / the incident is resolved.

Here’s a breakdown of how reassigning an incident can impact escalations, with examples:

**Example 1 - Change Team of an Incident: Assign Incident from Team A to Team B**

1. Team A: Auto-escalations stop as soon as the incident is not longer within the team.
2. Team B: Tier 1 members are notified about the newly assigned incident. Auto-escalations begin, regardless of whether the incident was acknowledged by Team A before assigning it to Team B.
3. Team B:
   * Team B settings: Stop auto-escalations when "**Incident is acknowledged**": Auto-Escalations as soon as anyone acknowledges the incident after it was assigned to Team B.
   * Team B settings: Stop auto-escalations when "**Incident is resolved**": Auto-escalations are only stopped if they come to an end or the incident is resolved.

**Example 2 - Escalate Incident to an Additional Team: Assign Incident from Team A to Team A & B**

* Team A Auto-Escalations: Tier 1 escalates to Tier 2 after **5 minutes**
* Team B Auto-Escalations: Tier 1 escalates to Tier 2 after **2 minutes**

1. Team A: Incident is created, and Team A's auto-escalations start (t=**0 min**)
2. Team A: The incident is assigned to Team A & B. (t=**2 min**)
3. Team A & B: At this point, Team B Tier 1 members and all already escalated tiers in Team A are notified about the newly assigned incident (t=**2 min**). Team B’s auto-escalations begin.
4. Team B: Auto-escalates to Tier 2, 2 minutes after Tier 1 was notified (t=**4min**)
5. Team A: **Contrary to Team A’s original auto-escalation plan**, auto-escalations now align with the updated escalation timeline. Auto-escalation for Team A also takes place at t=**4 min**. When multiple teams handle one incident and have different auto-escalation timelines, the system uses the first auto-escalation policy to align all teams. Team A is escalated regardless of whether Team A' settings stopped auto-escalations before the incident was assigned it to Team B. Adding a new team is treated as if the new Team B represents a new escalation tier, notifying all tiers below in Team A & B.
6. Team A & B:
   * **Both** teams **stop auto-escalations** when "**Incident is acknowledged**": Auto-escalations stop as soon as anyone acknowledges the incident after it was assigned to Team A & B.
   * At least **one** team **only stops** auto-escalations when "**Incident is resolved**": Auto-Escalations in Team A & B are only stopped if they come to an end or the incident is resolved.

### Repeat Escalations

You might want to repeat the escalation tiers to re-alert the on-call members.
At the bottom of the page, you will find an element that you can activate by clicking on the label.

<img />

Clicking the label opens an overlay.

1. Enabling the toggle activates repetition of all escalation tiers. Of course, tiers are only repeated if and after all escalations tiers have been reached.
2. Decide when auto-repeat should stop, whether it's when the incident is [acknowledged](/essentials/incident#history-acknowledged) or whether auto-repeat should happen until someone `Resolves` the incident.
3. You can select how often you'd like to repeat the escalations.
4. You can select how long you want to wait after the last escalation tier before repeating the escalations. We will use this grace period before restarting the escalations and re-alerting.
5. Save your settings.

<img />

This is an example of how escalations could be repeated.

<img />

### Auto Fill-up From Higher Escalation Tiers

We understand that it's critical to avoid any gaps in your team's weekly on-call shifts. Therefore, we added an auto fill-up feature that adds on-call team members from higher escalation tiers to lower escalation tiers if there is a gap in one of the lower-tier rotations.

Here's an example of how it works:

1. For simplicity, we are looking at a team with two on-call members in two tiers. Here, Tier 2 does not automatically come into play as there's no automatic escalation activated.
2. In Tier 1, Peer is usually on-call 24/7. However, due to a [personal override](/essentials/escalations#personal-overrides), he's not on-call for the day.
3. Tier 2 is our "safety net", with Nikolas on-call 24/7. Since there's no auto-escalation to Tier 2, he's usually not informed about incidents automatically.
4. This is where the auto fill-up feature comes into play. Nikolas (Tier 2) fills Peer's (Tier 1) vacant spot during his absence. As a temporary Tier 1 member, he is the first to be automatically informed about any incidents. As soon as Peer is back on-call, he'll resume his place in Tier 1.

<img />

<Tip>Note that this feature also works for escalations with more than 2 tiers. Just like in the example, we recommend creating an extra tier that is usually not escalated to in addition to your team's on-call escalations. Make sure that there's always someone on-call in this "safety net" tier, for example, by adding multiple team members. This way, you can easily protect your on-call rotations against gaps created by vacations and unexpected sick days.</Tip>

## Schedules

Within the management of escalations, All Quiet allows you to define schedules for each escalation tier. These schedules determine the on-call periods for team members. With schedule customization, you can specify the time of day, such as 8:00 AM to 4:00 PM, and designate specific weekdays, such as Monday through Friday, for the schedule to be active. This flexibility enables precise control over when team members are available and responsible for incident response within each escalation tier.

To edit the on-call periods of a schedule, simply click on the label located at the top left of the schedule. By clicking on the label, you can access the edit dialogue where you can modify the schedule's settings. The label will display the current settings, which are set to "everyday" by default, indicating that no specific settings have been defined yet.

<img />

In the edit dialogue, you can set a [start and end date](/essentials/escalations#start-and-end-date) for the schedule and define `On-Call Times`.

For now, we will focus on the `On-Call Times`. You can add as many on-call times as you like for one specific schedule. To start, click `+ Add On-Call Time`. A schedules default on-call time is 24/7.

<img />

In this example, we want to create a schedule for the weekend, starting on Friday afternoon at 17:00 and ending on Monday morning at 08:00.

1. As a start time, we set 17:00. Leaving the "until" field empty will be interpreted as "until end of the day", just like leaving the "From" field empty would be interpreted as "from the start of the day".
   <Note> Select an end time smaller than or equal to the start time to create an overnight schedule that ends the next day.</Note>
2. Additionally, we select the weekdays when the members of the schedule should be on-call from 17:00 - end of the day by checking the corresponding checkbox for Friday.
   <Note>Checking no box would mean that the schedule would be active every weekday starting from 17:00</Note>
3. We can see that the schedule is set to be active on Fridays after 17:00. The label updates as you adjust the settings, showing your current setup.
4. We still need to add the on-call times for Saturday-Monday.

<img />

1. Saturday and Sunday, we want the schedule to be active all day, so we just select the checkboxes for the days and don't enter any "From" or "Until" values.
2. Monday, we want the schedule to be active untill 08:00, so we only enter an "Until" time.
3. The label updates accordingly.
4. Clicking `Save Schedule` activates the new schedule settings.

<img />

1. After saving, you will immediately see the current schedule's settings displayed in the top left corner. This provides a clear and easily understandable representation of the saved schedule settings, ensuring visibility and quick reference to the configured on-call periods and weekdays.
2. Also, if you open your [team's calendar](/essentials/escalations#team-calendar), you will see how the schedule and it's [rotations](/essentials/escalations#rotations) will take effect.

<img />

<img />

Check out our example [below](/essentials/escalations#example-setting-up-an-on-call-rotation) for a hands-on use case setting up two schedules within an escalation tier.

### Round Robin Alerting

Round Robin ensures fair and structured incident distribution, preventing any single person from being overwhelmed.

While our [**Rotations feature**](/essentials/escalations#rotations) automatically **cycles on-call responsibilities over time** (e.g., week over week for fair coverage), **Round Robin** steps in when **multiple people are on-call simultaneously** - assigning incidents in a rotating order.

This guarantees:

* ✅ No one gets overloaded with back-to-back incidents.
* ✅ Every on-call member stays informed and engaged.

At All Quiet, you can activate Round Robin for each schedule seperately. When enabled, Round Robin distributes incidents evenly among all users who are on-call at the same time within this schedule.

To activate Round Robin for a schedule, first click the "No Round Robin" button.

<img />

An overlay opens:

1. Enable Round Robin
2. Define the number of users per incident. This determines how many users are assigned per incident before cycling to the next in the queue for the next incident.
3. Save your settings.

<img />

Here's a little example how it works in practice:

1. In my schedule, there are 3 users (Peer, Nikolas, Max) on-call at the same time.
2. I've enabled Round Robin with a size of 2. For each incident, instead of alerting all three on-call colleagues, we will notify only two, rotating the selection for each incident.

<img />

Here's how alerting will rotate with the Round Robin settings from above:

| # Incident | Notified On-Call Members |
| ---------- | ------------------------ |
| Incident 1 | Peer, Nikolas            |
| Incident 2 | Peer, Max                |
| Incident 3 | Niklas, Max              |
| Incident 4 | Peer, Nikolas            |
| ...        | ...                      |

### Start and End Date

For each schedule, you can optionally define a start and an end date.

<Info>"Valid From" replaces the deprecated "Effective From" field in the rotation settings. "Valid From" specifies from which date onwards this schedule should be used. If you want to start the schedule right away, you don't need to use this field.</Info>

In this example, we set "Valid From" and "Valid Until" to define the schedule for one week only.

<img />

In the calendar, you can see that the schedule is only active for the selected week.

<img />

## Rotations

At All Quiet, `Rotations` can be added on `Schedule` level. Rotations ensure fair distribution of on-call responsibilities among team members.

To add rotations to a schedule, simply click on the label located at the top right of the schedule. It always shows the current rotation settings of the schedule, which are set to `No rotation` by default.

<img />

Clicking on it will open the rotation settings dialogue, allowing you to configure and customize the rotation settings according to your requirements.

First, you need to decide for the desired `Rotation Mode`.

* No Rotation (default)
* [Auto](/essentials/escalations#auto-rotations)
* [Explicit](/essentials/escalations#explicit-rotations)

Below, we'll explain how both auto and explicit rotations work.

<img />

### Auto Rotations

Auto-rotations create rotations for all members of a schedule without having to add rotations groups manually. All users can be added to one single group.

In the example below, we have 3 members in the Tier 1, Schedule 1.

1. Currently, all Members are on-call.
2. To add an auto-rotation, click the `No rotation` button.

<img />

1. Next, we opt for `Auto` as rotation mode. This mode will automatically rotate the group of users in the schedule.
2. Define the `Auto Rotation Size`. This is the number of persons on-call in each rotation group.
3. Select how oftern on-call duties should rotate. You can choose between
   * Daily
   * Weekly
   * Biweekly
   * Monthly
   * Custom
4. With rotation period weekly, you can also set a `Handoff Day`. When your [schedule](/essentials/escalations#schedules) uses 24-hour shifts and no specific on-call times, you can set a `Handoff Time` for the on-call duty, too. If no `Handoff Time` is available, the handoff happens automatically after the first shift ending that day (for overnight schedules) or before the first shift starting that day.
5. Click `Save Rotation` to activate your changes.

<Info> The "Effective From" option got deprecated. Instead, you can now set a ["Valid From"](/essentials/escalations#start-and-end-date) date on schedule level.</Info>

<img />

1. As you can see, only 2 members of the group are on-call (green dots), the other has time off (red dot). By editing the members, you can change the rotation order per drag-and-drop.
2. Next Monday at 00:00, the next 2 members will automatically rotate in for on-call duty. One week after, the next 2...

You can check your [team's calendar](/essentials/escalations#team-calendar) to see how the rotation will affect future on-call responsibilities.

<img />

<Tip> If you add new users to a schedule with `Auto Rotations`, they are automatically included in the rotations. If you remove users, the rotations are automatically adjusted to fill the gaps.</Tip>

### Explicit Rotations

1. With `Explicit` rotation mode, you manually define the members of each rotation group in the next step.
2. With rotation period weekly, you can also set a `Handoff Day`. When your [schedule](/essentials/escalations#schedules) uses 24-hour shifts and no specific on-call times, you can set a `Handoff Time` for the on-call duty. If no `Handoff Time` is available, the handoff happens automatically after the first shift ending that day (for overnight schedules) or before the first shift starting that day.
3. Select how oftern on-call duties should rotate. You can choose between
   * Daily
   * Weekly
   * Biweekly
   * Monthly
   * Custom
4. Click `Save Rotation` to activate your changes.

<Info> The "Effective From" option got deprecated. Instead, you can now set a ["Valid From"](/essentials/escalations#start-and-end-date) date on schedule level.</Info>

<img />

1. We've opted for `Explicit` rotations, so we need to add at least a 2nd `Rotation`.
2. Click `+ Add Rotation` to create a new rotation and add members to it.

<img />

After adding a 2nd rotation,

1. we can see that one rotation is on-call (green dot) and the other has time off (red dot) until on-call duties rotate. You can change the rotation order per drag-and-drop.
2. Here, we can see our rotation rule and edit it.

You can check your [team's calendar](/essentials/escalations#team-calendar) to see how the rotation will affect future on-call responsibilities.

<img />

### Adding / Removing Rotations

When you add or remove rotations, we make sure the current on-call rotation remains active and the order stays unchanged.

<Warning>**Exception when using "Valid From" in schedule**</Warning>

When the first rotation begins after the "Valid From" date in a cycle, that rotation marks the start of the plan. For example, in a weekly cycle where the "Valid From" date falls on a Tuesday:

* If the rotation start day is Monday or Tuesday, the on-call period begins on Tuesday (the "Valid From" date).
* If the rotation’s designated handover day is Thursday, then the on-call period begins on the first Thursday after the "Valid From" date -  two days later.

## Team Calendar

To view the calendar of a team and gain an overview of team members' on-call and off-call periods within each escalation tier, follow this step:

### Access Team Calendar Page

Access the team calendar page: Navigate to the team management section or select the specific team from the menu. Look for the option labeled `Calendar`.

<img />

### View Team's Calendar and Schedules

The All Quiet calendar provides a visual representation of the on-call schedules for your teams, ensuring that everyone knows their responsibilities at a glance. Below is a breakdown of the key elements of the calendar interface:

### Monthly Calendar

1. **On-Call Now Indicators:** These indicators provide a quick view of which team members are currently on-call. The indicators are color-coded and numbered to correspond with the tier of on-call duty.
2. **Tiers Filter:** Use the `Tiers` dropdown to filter the calendar view by on-call tiers. This allows you to focus on specific response levels within your team's on-call schedule.
3. **Individual Schedule Entries:** These entries display the scheduled on-call shifts for each team member. The entries show the profile image of the on-call individual and the corresponding time period of their shift. Click on the shift for details.
4. **Tier Labeling:** Each schedule entry is labeled with a 'T' followed by a number to indicate the on-call tier. 'T1' corresponds to Tier 1, and 'T2' to Tier 2, providing a clear distinction of responsibility levels.
5. **Time Navigation:** This section allows you to navigate through different time frames within the calendar—'Week' and 'Month' views are available. Use the arrows to move backward or forward through the calendar.
6. Click `Today` to return to the current date.

<img />

Clicking on a shift in the calendar opens an overlay that gives you more details.

<img />

### Weekly Calendar

The weekly view in the All Quiet calendar provides a detailed look at the team's on-call schedule, with each day of the week displayed as a separate column. This view contrasts with the monthly perspective by offering a granular, day-by-day breakdown of on-call shifts.

* **Daily Details:** Unlike the monthly view which summarizes the shifts, the weekly view displays individual shifts for each day, showing precise start and end times.
* **Current Day Highlight:** The current day is accentuated with a distinct color, making it stand out for easy identification.
* **Hourly Breakdown:** Each column represents a single day broken down by hour, which is more detailed than the monthly calendar.

<img />

### Team Member Overrides

**Team Administrators** can enter the `Team > Overrides` section to add overrides for all team members.
In order to do so, select the team you want to add an overrride to.

1. Next, select `Overrides`
2. Click `Add Team Override`

<img />

This action opens and overlay.

1. Select the duration of the override.
2. Specify whether the override should `apply to all teams` of the selected user or whether it should only `apply to this team`.
3. Specify whether the override should be appplied to all tiers or only specific tiers.
4. Specify the type (“Offline” or “Online”), the user(s) for whom you want to create the override, and - if the user(s) will be “Offline” - optionally the covering user who will replace the offline user(s) in their shift(s). You can select **multiple offline users** and assign **one covering user** to take over all of their on-call shifts during the override period.
5. Save the override. It will be visible in your team's calendar and show up in the related users' [personal availabilites](/essentials/escalations#personal-availability).

To create a similar override with different dates or users, open an existing team override and click **Duplicate**. This copies the override settings so you can adjust them before saving.

<img />

### Publish and Export Team Calendar

<Info>The Team Calendar can only be published by *Team Administrators*, *Organization Administrators* and *Organization Owners*. Users with respectible rights can share the .ics link with others.</Info>

The Team Calandar Export function allows you to create an .ics link that lets you sync your Team's All Quiet on-call schedule with your personal calendar. You can also open the .ics URL directly to download a one-time snapshot of your current shifts. This publshed Team Calendar is a great way for Team Leads to keep track of any gaps in the on-call rotation via your personal calendar.

To publish your Team's calendar,

1. Open the Calendar tab
2. Click on `Publish Calendar` below the calendar view.

<img />

In the Overlay,

1. Choose whether to **sync all tiers** or **just Tier 1**. <Note>If you’re using Google Calendar, remember to rotate your public calendar URL after changing your sync settings and embed the new URL.</Note>
2. After clicking `Publish Team Calendar URLs`, you will see your team's specific URLs that you can use to subcribe to the All Quiet On-Call calendar from your private calendar. Simply click on the URLs to copy them.
3. If you click **“Rotate Team Calendar URL”**, a new calendar link will be generated. Any subscriptions using the old link will stop updating, so you’ll need to resubscribe with the new URL.

<img />

<Note>To ensure accurate synchronization to your private calendar, please verify that your Team's All Quiet calendar and private calendar are aligned to the same time zone.</Note>

<Tip>
  Calendar apps like Google, Outlook, and Apple handle subscriptions differently. To subscribe to your Team's All Quiet on-call calendar, please follow the instructions for your specific calendar app. Keep in mind that it may take **12–24 hours** for the first events to appear and for updates to sync based on your specific calendar app's polling settings.
</Tip>

## Personal Availability

This section in All Quiet's documentation focuses on the crucial aspect of managing personal availability, ultimately contributing to a calm and efficient working environment, ensuring smooth coordination and coverage for on-call responsibilities.

### Your Availability

I the top left corner of the Web App, next to your Username, you can find a dot which dynamically indicates your current on-call status by displaying a blinking red or green indicator.

Clicking on your Username opens a drop down in which you will find links to your personal `Overrides` and your personal `Calendar`. Clicking on of these links will navigate you to the "Calendar" section, which consists out of three tabs.

1. `Your Calendar` where you can conveniently view all your upcoming on-call duties across various teams.
2. An overview of your [personal Overrides](/essentials/escalations#personal-overrides).
3. A page where you can [generate a public calendar URL](/essentials/escalations#export-personal-on-call-calendar) to export your personal on-call times and import them to your favorite calendar app.

<img />

### Personal Overrides

You can create overrides, such as a "fill-in" for a colleague on vacation or for your own vacation, with specified start and end dates.
Simply click the `Add personal override` (2) button on the `Overrides` (1) tab.

<img />

1. A calendar will appear, allowing you to select the start date and end date.
2. Specify whether the override should apply to `All teams` you're a member in or whether it should only apply to a `Specific team`.
3. Specify whether the override should be appplied to all tiers or only specific tiers.
4. Select the type of override

* ``I`ll be offline``: You're offline for the selected time (e.g because you're sick or on vacation). Optionally, add colleagues who will cover your on-call shifts in your shared team(s).
* ``I`ll be covering``: You'll be on-call and take care of the on-call shifts of one or more offline colleagues in your mutual team(s). You can cover **multiple colleagues in a single override**.
* ``I`ll be online``: You'll be on-call in Tier 1 in all teams in which you have an explicit [membership](/essentials/teams#roles).

This intuitive process enables you to establish personalized overrides with fixed durations, ensuring accurate representation of your availability during specific periods.

To create a similar override with different dates or colleagues, open an existing personal override and click **Duplicate**. This copies the override settings so you can adjust them before saving.

<img />

### Export Personal On-Call Calendar

After you click “Generate Public Calendar URL”, we’ll create an .ics link that lets you sync your All Quiet on-call schedule with your personal calendar. You can also open the .ics URL directly to download a one-time snapshot of your current shifts.

1. If you click **“Rotate Public Calendar URL”**, a new calendar link will be generated. Any subscriptions using the old link will stop updating, so you’ll need to resubscribe with the new URL.

2. Choose whether to **sync all tiers** or **just Tier 1**. <Note>If you’re using Google Calendar, remember to rotate your public calendar URL after changing your sync settings and embed the new URL.</Note>

<img />

<Note>To ensure accurate synchronization to your private calendar, please verify that your personal All Quiet calendar and private calendar are aligned to the same time zone.</Note>

<Tip>
  Calendar apps like Google, Outlook, and Apple handle subscriptions differently. To subscribe to your All Quiet on-call calendar, please follow the instructions for your specific calendar app. Keep in mind that it may take **12–24 hours** for the first events to appear and for updates to sync based on your specific calendar app's polling settings.
</Tip>

### Vacation Schedule

The screenshot demonstrates an example of an individual vacation schedule (marked as "offline") spanning a full week. However, it is worth noting that if the user should have been on call during this period, we would have still indicated this with green schedules on the same days. To modify or remove an existing override, simply click open the personal Overrides tab and edit the respective override.

<img />

### On-Call Reminder

Stay informed with our automatic on-call reminders. By default, you'll get an email one day prior to your shift to help you prepare. Prefer not to be reminded? No problem. Just deselect the reminder in your account settings.

<img />

## Timezones

Managing time zones in All Quiet is straightforward, ensuring your team's schedules and rotations are always synced. Here's how it works:

* **Time Zone Setting:** The team's default time zone is initially set to the creator's time zone but can be easily adjusted to fit your team's geographical distribution.
* **Unified Scheduling:** Regardless of individual locations, all schedules align with the team's chosen time zone, making coordination seamless.
* **Flexibility:** [`Team Administrators`](/essentials/teams#roles) can update the team's time zone at any time via the [Edit](/essentials/teams#edit-team) tab to reflect changes in team's composition or operational needs, keeping everyone in sync effortlessly.
  This setup ensures seamless team operation across locations, streamlining time zone management and collaboration.

## Example: Setting up an on-call rotation

In this setup, we aim to ensure round-the-clock incident coverage with a focused approach:

* A team of four splits into two engineers on-call weekly (24/7) and two engineering managers on half-day shifts.
* Engineers rotate each week for continuous Tier 1 coverage.
* Engineering managers cover Tier 2 in two 12-hour shifts: 0-12 and 12-24.
* Auto-escalation: Escalate from Tier 1 to Tier 2 after 10 minutes if nobody acknowledges.
* If both Tier 1 and 2 miss an incident, the escalation is repeated once after 20 minutes

<Steps>
  <Step title="Add first schedule">
    In your team, go to `Schedule & Escalations`, click on `+ Add Escalation Tier 1` & add both engineers to it.

    <img alt="oncall01" />

    <img alt="oncall02" />
  </Step>

  <Step title="Create an auto-rotation for your schedule">
    We want to add auto-rotations to the first schedule, so we click on the `No rotation` label.

    <img alt="oncall03" />
  </Step>

  <Step title="Edit Rotation">
    1. Duty should rotate automatically.
    2. For each rotation, we want 1 on-call person.
    3. You want on-call duty to rotate `weekly`.
    4. We want to rotate on-call duty on Mondays at midnight.
    5. Click `Save Rotation` to activate the auto-rotation.
       <img alt="oncall04" />
  </Step>

  <Step title="Create a New Tier">
    You're done with Escalation Tier 1 and can set up subsequent Escalation Tiers to ensure no incident goes unnoticed.

    1. Under the subsequent Escalation Tier, click on  `+ Add Escalation Tier 2`
    2. Choose the members that you want to add to Escalation Tier 2's first schedule. Remember, in this escalation tier we'll want to define two schedules since our team members are located in different time zones which ensures they only receive incidents during daytime (i.e., follow-the-sun rotation). So we only add only one member to the first schedule.
       <img alt="oncall05" />
    3. Next, we ensure auto-escalation is set up between Tier 1 and 2. Click on the label between the two tiers.
       <img alt="oncall06" />
    4. We want to auto-escalate to Tier 2 (1) after 10 minutes (2) if not acknowledged (3) for all severities (4) and at all times of the week (5). Save the Tier 1 escalation settings (6).
       <img alt="oncall06a" />
  </Step>

  <Step title="Customize Schedules">
    Now, we need to customize the schedule of the engineering manager to account for their half-day shift.

    1. Click on `everyday` to edit the schedule & adjust the daily hours to 00:00-12:00.
    2. Add a second schedule for the other engineering manager...
       <img alt="oncall07" />
       ... and activate it Mon-Sun from 12:00-24:00.
       <img alt="oncall08" />
  </Step>

  <Step title="Repeat escalations if no one reacts">
    If no one acknowledged an incident 20 minutes after escalation to Tier 2, we want to repeat the escalations once.

    <img alt="oncall09" />
  </Step>

  <Step title="Check your Calendar">
    We're done now and can check our on-call rotation directly under `Calendar`. Also, you'll always see who is currently on-call in your relevant tiers.

    <img alt="oncall10" />
  </Step>
</Steps>

## Common setups and troubleshooting

### Weekend on-call through Monday morning

**Goal:** The same person stays on-call from Friday evening through Monday morning (for example **Friday 17:00** → **Monday 09:00**), and the **weekly** rotation should change **after** that weekend duty ends—not at **Monday 00:00** while someone still needs to cover Monday morning.

**Handoff time only applies to 24-hour coverage:** As described under [Auto Rotations](/essentials/escalations#auto-rotations), you can set a `Handoff Time` only when the schedule uses **24-hour shifts** and **no specific on-call times**. For weekend windows made of shorter blocks, that option is not available—the handoff is derived from your **handoff day** and how the **on-call times** fall on that day.

**How Monday as handoff day behaves without `Handoff Time`:** Again per [Auto Rotations](/essentials/escalations#auto-rotations), the handoff happens automatically **after the first shift ending that day** (for overnight-style coverage) or **before the first shift starting that day**. That is why a seemingly “simple” weekend pattern can rotate at the wrong moment.

**Pattern to avoid:** Friday **17:00**–end of day, Saturday and Sunday **full day**, plus a **separate** Monday-only window **00:00–09:00**. On Monday, the first on-call segment **starts at 00:00**, so the rotation is tied to that shift—you do **not** get a handoff at **09:00** when weekend coverage ends.

**Recommended pattern:** Keep the same overall coverage, but end the weekend with **one** on-call time that runs **Sunday 09:00 → Monday 09:00** (use an end time not later than the start time so the block ends Monday morning, as in the [schedule editor](/essentials/escalations#schedules)). Together with **Friday 17:00 → Saturday 09:00** and **Saturday 09:00 → Sunday 09:00**, the Monday rotation lines up **after** that Sunday–Monday block ends—i.e. when you intend weekday coverage to take over.

**At a glance — on-call times in the weekend schedule**

* **Friday:** **17:00–09:00** *(next day)*
* **Saturday** and **Sunday:** each **09:00–09:00** *(next day)*
* **Rotation:** **Weekly**, handoff day **Monday** (no `Handoff Time` on this schedule—see above)

→ **Result:** Coverage through **Monday morning**; the rotation advances after that weekend duty ends, not at **Monday 00:00**.

Adjust times to match your team. Always verify the handoff in the [team calendar](/essentials/escalations#team-calendar).

For screenshots of the schedule UI, see the [weekend example](/essentials/escalations#schedules) under **Schedules**—apply the **Monday** end time using a single Sunday→Monday window instead of **Monday 00:00–09:00** as its own row if you need rotation after Monday morning handoff.


# Inbound Integrations
Source: https://docs.allquiet.app/essentials/inbound

Connect your observability stack to our platform

<Info> Find the list of all built-in inbound integrations at the [bottom of this page](/essentials/inbound#built-in-integrations).</Info>
Inbound Integrations are dynamic and flexible. The integration process is simple and involves a three steps:

1. Create the integration
2. Receiving a **payload**
3. Mapping payload **attributes** to incidents

Later, you may add snooze settings and maintenance windows.

## Create Inbound Integration

<Info> Only Team Administrators, Organization Administrators and Organization Owners have the permissions to create and edit Integrations.</Info>

<Note> **Call Routing Numbers** are an exception: only **Organization Administrators** and **Organization Owners** can create them. **Team Administrators** can edit existing numbers whose **Root Team** is a team they administer. See [Live Call Routing](/advanced/live-call-routing).</Note>

<iframe title="How to Connect Your First Observability Tool with All Quiet " />

To create a new integration,

1. navigate to the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

From there,

1. Give your integration a `Display Name`, such as "My Inbound Webhook".
2. You'll also need to choose which team the integration should belong to, as this can't be changed later.
3. Select the type of integration. Keep in mind that the integration type can't be changed later.
4. Click `Create Inbound Integration`

<img />

Next, we need to configure the integration. This includes:

1. The [Edit tab](/essentials/inbound#edit-your-integration’s-general-settings), in which you can find some generic information about your integration.
2. [Receiving a **payload**](/essentials/inbound#receiving-payloads) by connecting All Quiet to your Inbound Integration using a **unique Webhook URL**.
3. [**Mapping payload attributes**](/essentials/inbound#mapping-payloads) to All Quiet incidents.
4. Later, you may add [**Snooze settings**](/essentials/inbound#snoozing-inbound-integrations)
5. and [**Maintenance Windows**](/essentials/inbound#maintenance-for-inbound-integrations) for your integration.
6. Last, for each integration you can find your [Incident KPIs](/advanced/report#integration-level) in the `Incidents` tab.

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

<img />

## Edit Your Integration's General Settings

In this tab, you can make some general changes to your integration:

1. You can change your integration's `Display Name` for your team.
2. You may add `Labels` to your integration. Labels help categorize inbound integrations (e.g. by environment or source). They are combined with [team labels](/essentials/teams#edit-team) when [filtering incidents](/essentials/incident#filtering-incidents).

<img />

## Receiving Payloads

<Warning>Try to avoid personal data and security relevant information like credentials in the payloads sent to All Quiet. **For U.S. companies**: We are not HIPAA certified, so don't share individually identifiable health information protected by the HIPAA act. Make sure to exclude this kind of data from payloads sent to us.</Warning>

1. After creating a new integration, we find ourselved on the `Settings` tab of the integration details page. Here you can find integration's **unique Webhook URL**. Every request sent to this address will show up as a new payload in the [`Payload Mapping` tab](/essentials/inbound#mapping-payloads), from which we'll extract attributes and map these to incidents.
2. On webhook-based inbound integrations, optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads:
   * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
   * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.
   * If both are enabled, the request must pass both checks to be accepted.

<img />

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 on top of the tab. <Tip>Click on it to copy it.</Tip>
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. For each payload, you can see which incident it belongs to. Navigate to the incident by clicking on the shortened incident id on the payload tile.
   <Warning>**No payload in Latest Payloads?** If nothing shows up, the request never reached this integration. Most often the upstream system is posting to the **wrong Webhook URL** (wrong integration, old URL, or copy-paste error)—use the URL from this integration’s **Payload Mapping** or **Settings** tab. Also confirm the [integration](/essentials/inbound#built-in-integrations) is connected correctly, auth matches your setup, and the body is under **3MB**.</Warning>
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 in the [next section](/essentials/inbound#mapping-payloads). You can download your current payload mapping as Terraform resource by clicking the Terraform icon.
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 safe mapping changes and trigger test incidents to see if everything works as expected and save your mapping.

<img />

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 theme={null}
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"}'
```

Learn more about generic webhooks here: [Connect Generic Webhooks](https://allquiet.app/blog/connect-generic-webhooks).
<Tip>Each Inbound Integration type needs to be set up differently. Please refer to [each specific type's integration guideline](/essentials/inbound#built-in-integrations) for detailed setup instructions.</Tip>

## Mapping Payloads

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

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

#### 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 theme={null}
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"}'
```

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

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](/essentials/inbound#reserved-and-required-attributes).
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](/essentials/inbound#evaluation-types) and [mapping variables](/essentials/inbound#variables).
3. You can mark each attribute with `Grouped`, `Hidden`, `Image` or `Expand` key. More on this, [here](/essentials/inbound#optional-additional-attribute-keys).
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.

<img />

#### Handling Multiple Payloads

If your payloads can have different structures, you can adjust your payload mapping to account for that. You can simply add several entries for the same attributes that are evaluating different part of the payload. The first attribute that can be evaluated successfully will be added to the incident.
In the example below,

1. we 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 use the second Severity attribute in our mapping to statically set the Severity to Minor as our fallback.

<img />

<Tip> Make sure to also check our our video about handling multiple request formats and our mapping types, [below](/essentials/inbound#evaluation-types).</Tip>

#### Payload Mapping in Terraform

For our Terraform Provider, we've written a separate payload mapping ressource [allquiet\_integration\_mapping](https://registry.terraform.io/providers/AllQuietApp/allquiet/latest/docs/resources/integration_mapping).

If you don't use this resource, your integrations will implicitly follow our default mappings.

If you want to adjust the mapping, we've prepared  template `allquiet_integration_mapping` resources.

* Template Download (Example with Integration\_ID = "Datadog"): [https://allquiet.app/api/integrations/terraform/default/Datadog.tf](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](https://allquiet.app/api/public/v1/inbound-integration/types)

### Reserved and required attributes

<iframe title="Required, Reserved and Optional Attributes at All Quiet " />

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

| Property        | Description | Allowed Values                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |   |
| --------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | - |
| `CorrelationId` | Optional    | Use this attribute to uniquely identify and correlate your incidents. If omitted, a hash of all mapped custom attribute values is used — a payload is linked to the same incident **if and only if** all mapped attribute values are exactly the same. This is recommended to avoid creating new incidents when sending changing metrics (for example CPU consumption).                                                                                                                                                              |   |
| `Status`        | Required    | `Open`, `Resolved`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |   |
| `Severity`      | Required    | `Minor`, `Warning`, `Critical`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |   |
| `Title`         | Optional    | If omitted, defaults to your integration's name. After incident creation it cannot be updated by new payloads. However, a title can be [edited manually](/essentials/incident#edit-incident-title) in the web app and is **not overwritten** by later payloads.                                                                                                                                                                                                                                                                      |   |
| `Discard`       | Optional    | `True`, `False`: Setting `Discard` = `true` in **payload mapping** discards the incident **before it is created**. This is useful if you want to ignore certain payloads for instance based on HTTP method. Note that incidents Discarded via payload mapping are therefore **not included in [incident reports](/advanced/report#incident-report) / statistics**. In contrast, incidents discarded via a [**routing rule**](/advanced/routing#configure-actions) are created first and are therefore **counted in the statistics**. |   |

#### CorrelationId Flowchart

When a new payload is mapped, All Quiet uses `CorrelationId` to decide whether to open a new incident or merge into an existing one:

```mermaid theme={null}
flowchart TD
    A[New payload arrives] --> B{Open incident with this CorrelationId?}
    B -->|Yes| C[Update or resolve incident]
    B -->|No| D[Create new incident]
```

The payload’s mapped **`Status`** (`Open` or `Resolved`) determines whether the matched incident is updated or resolved. If you omit `CorrelationId`, All Quiet hashes all mapped custom attribute values instead — the same flow applies, but a payload is linked to an existing incident **only if every mapped attribute value matches exactly**.

### Optional, additional attribute Keys

| Type      | Description | Values  | How it Works                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
| --------- | ----------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Image`   | Optional    | Boolean | If your payload includes a URL, you can use this as an additional specification of an object to show the image in All Quiet                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
| `Hidden`  | Optional    | Boolean | When activated for attributes, these will not be shown in incident email and on the incident overview in Web and App, but only in the incident details.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
| `Grouped` | Optional    | Boolean | When setting Grouping = true for certain attributes, incidents that have the same values for these attributes will be [grouped](/essentials/incident#incident-grouping) as long as one of the group is `Open` and not `Resolved`. If you set isGroupingKey = true for more than one attribute, incidents will only be grouped if the values for all attributes match. When grouping is active for an integration, All Quiet checks the grouping attribute(s) **before** `CorrelationId`. A payload can only be correlated to (and update or resolve) an existing incident if the grouping attribute(s) also match. If a payload's `CorrelationId` matches an **open subincident** in an open group, that subincident is updated or resolved — the same as for incidents without grouping, even when **`groupingWindowInSeconds`** is configured. Map **`groupingWindowInSeconds`** to limit when **new subincidents** (new `CorrelationId` values) are added to an existing open group: the window is measured in seconds since the **last update** on any incident in the group. After it expires, payloads with a **new** `CorrelationId` create a new incident group and may alert your on-call colleagues again. |
| `Expand ` | Optional    | Boolean | When enabled, after all mapping steps for this attribute the pipeline value is parsed as JSON. Each top-level object key or array index becomes a separate incident attribute (for example, jsonBody.cluster, jsonBody.alertname) for use in routing rules. Nested values stay a single string per key. The **last value must be valid JSON** (object, array, or scalar), otherwise `Expand` = true will break the attribute. Use any mapping steps you need to produce that string.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |

#### Grouped Flowchart

When **`Grouped`** is enabled on one or more attributes, All Quiet checks grouping **before** `CorrelationId`. Incidents with the same values for all grouping attributes are collected into one group while that group is `Open`:

```mermaid theme={null}
flowchart TD
    A[New payload arrives] --> B{Open group with matching grouping attribute values?}
    B -->|No| F[Create new incident — starts a new group]
    B -->|Yes| C{CorrelationId matches an open subincident in the group?}
    C -->|Yes| D[Update or resolve subincident]
    C -->|No| GW{Grouping window enabled?}
    GW -->|No| E[Add new subincident to group]
    GW -->|Yes| W{Payload within grouping window after last update in group?}
    W -->|No| F
    W -->|Yes| E
```

If you mark more than one attribute as `Grouped`, values must match on **all** of them for incidents to land in the same group. After the group is `Resolved`, the next matching payload creates a new group and alerts your on-call colleagues again.

<Note>Map **`groupingWindowInSeconds`** to enable the grouping window. The window is measured in seconds since the **last update** on any incident in the group. It applies only when adding a **new subincident** (a `CorrelationId` not already present as an open subincident in the group). After it expires, payloads with a **new** `CorrelationId` create a new group and may alert again — even if a previous group with the same grouping values is still `Open`. Payloads that match an **open subincident's** `CorrelationId` still **update or resolve** that subincident, the same as for incidents without grouping.</Note>

More on **Incident Grouping** in the video below.

<iframe title="Group Incidents to Reduce Noise | All Quiet Payload Mapping Guide" />

### Evaluation Types

<iframe title="Mapping Evaluation Types & Handling Multiple Request Formats at All Quiet" />

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

| Type       | Description                                                                                                                                                                                                                                                                               |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `jsonPath` | A JSONPath expression to map JSON ([goessner.net/articles/JsonPath](https://goessner.net/articles/JsonPath/))                                                                                                                                                                             |
| `xPath`    | A XPath expression to map HTML or XML. ( [w3schools](https://www.w3schools.com/xml/xpath_intro.asp))                                                                                                                                                                                      |
| `regex`    | A regular expression to extract parts of text. The regex is evaluated with the .NET/C# flavor. If groups are matched, the named group "result" is returned. If no group is named "result" the last group is returned. If no groups are found the whole match is returned. ( regex101.com) |
| `map`      | A simple map expression mapping values from A to B. The expression A->1,B->2,->3 will map the value "A" to "1" and "B" to "2" and fallback to "3" if no match is found. You can also omit the fallback. The result will then evaluate to the original value.                              |
| `static`   | A static string. The result will always be this string.                                                                                                                                                                                                                                   |

### Variables

<iframe title="Advanced Payload Mapping - Using Variables at All Quiet " />

You can also use **variables** in any of your mapping steps if the related attribute was already defined above.

For example: `{{ previousIncident.status }}` will work if attribute "status" was already defined in a mapping above. If the attribute "status" is defined below the attribute that uses the variable `{{ previousIncident.status }}`, the variable won't work.

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:

```JSON ConcatenationWithVariables.JSON theme={null}
{
  "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:

```JSON JSONPathExample.JSON theme={null}
{ "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:

```HTML theme={null}
<body>
    <table>
        <tr>
            <td>Severity</td>
            <td>Critical</td>
        </tr>
        <tr>
            <td>Server</td>
            <td>prod1</td>
        </tr>
    </table>
</body>
```

#### Regex examples

<Tabs>
  <Tab title="Extract value after colon">
    To get the value "my-server" after a colon followed by space use `[: ](?[^: ]*)$` for the following text:

    ```
    Any label here: my-server
    ```

    Note the use of the named group "result". Since it's the only group, the naming of the group could also be ommitted.
  </Tab>

  <Tab title="Extract value after specific label">
    To get the value "my-server" after a label e.g. "SPECIFIC label here: " use `(SPECIFIC label here: )(.*)` for the following text:

    ```
    SPECIFIC label here: my-server
    ```

    Note that the groups are not named because the result is in the last group which is returned by default.
  </Tab>

  <Tab title="Extract value before colon">
    To get the value "ERROR" before a colon use `^[^:]*` for the following text:

    ```
    ERROR: your-check on your-project on server app-1
    ```
  </Tab>
</Tabs>

### 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 `Send Payload` to start the simulation. You'll observe the full cycle of incident processing as if it were a genuine alert.

<img />

## Snoozing Inbound Integrations

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 `Snoozing` 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](/essentials/incident#manually-snooze-%2F-unsnooze). 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. Also, [outbound integrations](/essentials/outbound) are muted while an incident is snoozed - except incidents are explicitly [forwarded](/essentials/incident#forwarding). In this case, a one-time request is sent to the specific outbund integration.
* Once unsnoozed - no matter if manually or because the snooze window ends - Tier 1 on-call members are alerted and any potential [auto-escalations](/essentials/escalations#automatic-escalation) 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](/essentials/incident#include-snoozed-incidents) in the incident overview.

<img />

## Maintenance for Inbound Integrations

In this tab, 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.

<img />

## Incident Report for Inbound Integrations

To learn more about your Integration's Incident KPIs, check our your [Integration's Incident Report](/advanced/report#incident-report).

## Troubleshooting: Missing or Unexpected Incidents

<span />

If an alert did not show up the way you expected—**no new incident was created**, **no notification was sent**, or it feels like the event “disappeared”—that rarely means the payload is missing. Inbound requests **typically appear** in the integration’s **Latest Payloads** on the **[Payload Mapping](#mapping-payloads)** tab. What varies is **what All Quiet did with the payload**:

* The incident may have been **discarded** (maintenance, payload mapping, or routing ruled that the payload should not be creating an incident).
* It may have **updated an existing Open incident** (same **`CorrelationId`**, Grouping attributes, or equivalent matching) instead of creating a new one. Can especially happen with **older Open incidents that weren't Resolved** that are **muted**, **snoozed**, **archived**, or otherwise **not notifying**, so you only see a quiet update.
* **[Advanced routing](/advanced/routing)** can still **mute channels**, **mute outbound integrations**, or **snooze**  and **discard** after creation.

To debug, start by opening **Latest Payloads** and the incident linked from the payload tile (below). Then work through the sections that match what you see.

### Latest Payloads: See Which Incident Received the Payload

<span />

1. Open the integration’s **[Payload Mapping](#mapping-payloads)** tab and inspect **Latest Payloads**.
2. Each tile shows which incident the payload was applied to. Click the **shortened incident id** on the tile to open that incident—this is the fastest way to see whether a **new** incident was created or an **existing** one was updated.

<img alt="Payload Mapping tab: Latest Payloads tiles with the incident id link highlighted" />

If a payload is **genuinely** not listed in **Latest Payloads**, it **did not reach** All Quiet. In practice that almost always means it was **not sent to the correct endpoint**: copy the **Webhook URL** from the integration’s **[Payload Mapping](#mapping-payloads)** tab (or **Settings**) and fix the sender configuration—wrong team, wrong integration, or a stale URL is the usual cause. After that, still verify **authentication** (if configured), **network** reachability, and the **request size limit** (see [Receiving Payloads](#receiving-payloads)).

### The Payload was Discarded

<span />

1. **`Discard` in payload mapping:** If mapping evaluates **`Discard`** to `true` for this payload, nothing is created—see [Reserved and required attributes](#reserved-and-required-attributes).
2. **Routing rule with Discard:** [Advanced routing](/advanced/routing) can **[Discard](/advanced/routing#configure-actions)** matching incidents **after** creation.
3. **Integration maintenance:** Under **[Maintenance for inbound integrations](#maintenance-for-inbound-integrations)**, **Maintenance** mode accepts the payload but **does not** create an incident.
4. **Team maintenance:** **[Maintenance](/essentials/teams#maintenance-mode)** (non-**Muted**) on the team prevents **new** incidents during the window.

### The Payload Updated an Existing Incident and No Notification was Sent

<span />

New payloads are often merged into an **already `Open`** incident that shares the same **`CorrelationId`** (or the same mapped attributes when `CorrelationId` is not set). See [Reserved and required attributes](#reserved-and-required-attributes). With [grouping](#optional%2C-additional-attribute-keys) enabled, the same applies to **open subincidents** in a group — including after **`groupingWindowInSeconds`** has expired. A payload may also match an existing open group and add a **new subincident** instead of creating a standalone incident.

Per default, notifications for simple **updates** of incident attributes or new subincidents are not sent.

<Info>**Title** from payload mapping applies when the incident is **created**. If someone later [edits the title](/essentials/incident#edit-incident-title) in the web app, subsequent webhook upserts **do not overwrite** that manual title. Other mapped attributes still update as usual.</Info>

1. Use **Latest Payloads** (above) to see **which** incident received the update.
2. Inspect that incident: it may be **[snoozed](#snoozing-inbound-integrations)** or sitting under an [integration](#maintenance-for-inbound-integrations) / [team](/essentials/teams#maintenance-mode) that is **muted**, so **no notifications** fire even though the payload was processed.
3. Find the **`CorrelationId`** (or [Grouping](/essentials/incident#incident-grouping) attributes) and search for other **Open** incidents with the same value. **Resolve** or clean up incidents that should no longer receive correlation so new events surface as expected.
4. Check **[archived](/essentials/incident#archiving)** incidents and use **[Include Snoozed](/essentials/incident#include-snoozed-incidents)** on the overview so hidden incident that might have swollowed the payload because of matching correlation are visible.

**Grouping:** If you use **grouping** keys, correlation also depends on those attributes—see [Incident grouping](/essentials/incident#incident-grouping) and [optional attribute keys](#optional%2C-additional-attribute-keys).

### New Incident Exists but Still no Notification

<span />

If **Latest Payloads** shows a **new** incident was created, but nobody was alerted:

1. **Created as `Resolved`?** Check **incident details**, or go to **Payload Mapping**, select the payload tile under **Latest Payloads**, and read the **preview**. If the mapping produces a **`Resolved`** incident, you will not get the usual notifications and escalations as for an `Open` incident.
2. **Integration snooze?** New incidents can be created already **[snoozed](#snoozing-inbound-integrations)**—use **[Include Snoozed](/essentials/incident#include-snoozed-incidents)**.
3. **Integration or team muted?** **[Muted](#maintenance-for-inbound-integrations)** integration or team **[maintenance (Muted)](/essentials/teams#maintenance-mode)** suppresses notifications.
4. **Advanced routing:** Check whether any **[routing rule](/advanced/routing)** whose **conditions match** this incident (after payload mapping) runs an action that suppresses alerting—for example **`Discard`** or or **Snooze** via [Configure Actions](/advanced/routing#configure-actions). Under [Choose Channels](/advanced/routing#choos-channels), you can mute all channels, all outbound integrations, or a subset of channels or outbound integrations. If this all is not the case, and outbound tools still never see the incident, also review [Forwarding](/essentials/incident#forwarding).

For a short list of these and other common flows, see [Troubleshooting & FAQs](/miscellaneous/troubleshooting).

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

<Tip>You can add the cloned version to a different team. The cloned version keeps the same payload mapping. If you you want to replace the old integration with the clode, update your observability tool by replacing the old webhook URL with the new one so alerts go to the new integration.</Tip>

<img />

## How to Use One Integration For Several Teams

<Note>To route incidents from one integration to several teams, all teams need to be within one [Organization](/advanced/organizations). Organizations are available on Pro and Enterprise plans.</Note>

Use a single shared inbound integration when several teams should receive alerts from the same source, but each team owns its own on-call and escalations. Common examples:

* **Same source, different on-call:** One Datadog monitor, AWS account, or webhook sends everything to All Quiet; [routing](/advanced/routing) assigns incidents to Platform, Backend, or Mobile so each team’s [escalation policy](/essentials/escalations) runs.
* **Split by topic or ownership:** Payload fields such as `service`, `team`, `product`, or `namespace` (mapped in [payload mapping](/essentials/inbound#mapping-payloads)) decide which team gets the incident—one integration, many destinations.
* **Severity-based handoff:** Critical incidents from the same integration go to a platform or incident-response team; Warnings and Minors stay with the product team that owns the service.
* **Environment or region:** One integration for staging and production (or `eu` vs `us`); route by `ENV`, `region`, or similar attributes so only the right team is paged.
* **Central “Root” team, no on-call there:** Integrations live in a Root team with no schedules; all real paging happens in domain teams after **Assign to Team** routing.

Here's how you can send incidents from one integration to multiple teams:

1. Create a "Root" [team](/essentials/teams#create-a-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.

<img />

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

<img />

3. Create [advanced routing rules](/advanced/routing) in the root team. Define for which conditions incidents are assigned to different teams.
   Below, you can find examples of different [routings](/advanced/routing) for incidents created via "Root" team's AWS CloudWatch integration. In the [payload mapping](/essentials/inbound#mapping-payloads), 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

<img />

Here's an example for an incident that got routed from "Root" to the team "Core".

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.

<img />

## 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:

<CardGroup>
  <Card title="AppDynamics" icon="chart-simple" href="/integrations/inbound/appdynamics" />

  <Card title="AppSignal" icon="crown" href="/integrations/inbound/appsignal" />

  <Card title="AWS Cloudwatch" icon="cloud" href="/integrations/inbound/aws" />

  <Card title="Azure Monitor" icon="cloud" href="/integrations/inbound/azure" />

  <Card title="Checkly" icon="check" href="/integrations/inbound/checkly" />

  <Card title="Coralogix" icon="circle-dot" href="/integrations/inbound/coralogix" />

  <Card title="Cron Job Monitor" icon="circle-notch" href="/integrations/inbound/cron-job-monitor" />

  <Card title="CrowdStrike" icon="crow" href="/integrations/inbound/crowdstrike" />

  <Card title="Dash0" icon="0" href="/integrations/inbound/dash0" />

  <Card title="Datadog" icon="dog" href="/integrations/inbound/datadog" />

  <Card title="Dynatrace" icon="cube" href="/integrations/inbound/dynatrace" />

  <Card title="Elastic Observability" icon="circle" href="/integrations/inbound/elastic-observability" />

  <Card title="Email" icon="envelope" href="/integrations/inbound/email" />

  <Card title="Google Cloud Monitoring" icon="cloud" href="/integrations/inbound/gcm" />

  <Card title="GitHub" icon="github" href="/integrations/inbound/github" />

  <Card title="GitLab" icon="gitlab" href="/integrations/inbound/gitlab" />

  <Card title="Grafana" icon="chart-pie" href="/integrations/inbound/grafana" />

  <Card title="Heartbeat Monitor" icon="heart-pulse" href="/integrations/inbound/heartbeat-monitor" />

  <Card title="Honeycomb" icon="hexagon" href="/integrations/inbound/honeycomb" />

  <Card title="Jira" icon="jira" href="/integrations/inbound/jira" />

  <Card title="Linear" icon="timeline" href="/integrations/inbound/linear" />

  <Card title="Mattermost" icon="power-off" href="/integrations/inbound/mattermost" />

  <Card title="Microsoft Teams" icon="microsoft" href="/integrations/inbound/microsoft-teams" />

  <Card title="Nagios" icon="N" href="/integrations/inbound/nagios" />

  <Card title="Netdata" icon="d" href="/integrations/inbound/netdata" />

  <Card title="New Relic" icon="chart-bar" href="/integrations/inbound/newrelic" />

  <Card title="Observium" icon="think-peaks" href="/integrations/inbound/observium" />

  <Card title="Ping Monitor" icon="server" href="/integrations/inbound/ping-monitor" />

  <Card title="Pingdom" icon="sun" href="/integrations/inbound/pingdom" />

  <Card title="Prometheus" icon="fire" href="/integrations/inbound/prometheus" />

  <Card title="PRTG Network Monitor" icon="gauge-low" href="/integrations/inbound/prtg" />

  <Card title="Rollbar" icon="horizontal-rule" href="/integrations/inbound/rollbar" />

  <Card title="Salesforce" icon="salesforce" href="/integrations/inbound/salesforce" />

  <Card title="Sentry" icon="triangle" href="/integrations/inbound/sentry" />

  <Card title="ServiceNow" icon="user" href="/integrations/inbound/servicenow" />

  <Card title="SigNoz" icon="eye" href="/integrations/inbound/signoz" />

  <Card title="Site24x7" icon="square-arrow-up" href="/integrations/inbound/site24x7" />

  <Card title="Slack" icon="slack" href="/integrations/inbound/slack" />

  <Card title="Splunk" icon="greater-than" href="/integrations/inbound/splunk" />

  <Card title="StatusCake" icon="cake-slice" href="/integrations/inbound/statuscake" />

  <Card title="Twilio" icon="phone-arrow-down-left" href="/integrations/inbound/twilio" />

  <Card title="UptimeRobot" icon="robot" href="/integrations/inbound/uptimerobot" />

  <Card title="Webhook" icon="webhook" href="/integrations/inbound/webhook" />

  <Card title="Website / HTTP Monitor" icon="monitor-waveform" href="/integrations/inbound/website-http-monitoring" />

  <Card title="Zabbix" icon="square-z" href="/integrations/inbound/zabbix" />

  <Card title="Zapier" icon="integral" href="/integrations/inbound/zapier" />
</CardGroup>

## Propose a new integration

Didn't find your tool here? Reach out to [support@allquiet.app](mailto:support@allquiet.app) and let us know your preferred integration. We're always happy to grow our integrations list.

## API and Webhook Rate Limits

<Info>Our current rate limits for all integrations in order to protect the functionality of the platform for all customers</Info>

* **API**: 30 unique requests per URL within 20s (Public API is rate limited separately)
* **Public API**: 300 requests per API Key within 20s, 2700 requests per API Key within 300s
* **Webhook Payloads**: 20 requests per integration within 3s, 50 requests per integration within 20s, 180 requests per integration within 300s
* **Incident Updates From Integration**: Max 256 updates without user interaction in between are saved for a single incident; once limit is reached, newer updates will override older attribute information.
* **Incident Creation via API**: 4 incidents within 30s, 10 incidents within 2min, 20 incidents within 5min.
* **Incident Updates via API**: 4 updates per incident within 30s, 10 updates per incident within 2min, 20 updates per incident within 5min.


# Incident Collaboration
Source: https://docs.allquiet.app/essentials/incident

Solve incidents faster with All Quiet

Explore how to manage incidents in All Quiet, including filtering, sorting, and searching, plus team collaboration techniques. This guide, focusing on the web app, mirrors the functionality you'll find in our mobile apps,

## Incidents Overview

Open `Incidents`. Per Default, it shows all `Open` incidents of your teams.
<Tip>For help when alerts, payloads, or notifications do not match what you expect, see [Troubleshooting inbound payloads & incidents](/essentials/inbound#troubleshooting-missing-or-unexpected-incidents) in **Inbound Integrations**.</Tip>

<img />

## Filtering and Sorting incidents

You can filter, sort and search incidents within All Quiet. We automatically save your filter settings.

### Sorting incidents

By default, incidents are sorted by `Urgency`. You can change this to `Latest interaction`, `Created` or `Title`by clicking on `Urgency`.

<img />

### Filtering incidents

You can filter the list of incidents based on:

* **Status:** `Open` or `Resolved`. Per Default, we only show `Open` incidents.
* **Severity:** `Critical`, `Warning` or `Minor`
* **Labels:** Choose between all labels of your [Teams](/essentials/teams#edit-team) and [Inbound Integrations](/essentials/inbound#edit-your-integration’s-general-settings), here.
* **Teams:** Choose between all of your teams here
* **Integrations:** Choose between all of your integrations here
* [**On-Call / Assigned Users:**](/essentials/incident#filter-for-on-call-%2F-assigned-users) Display only incidents where the selected users were on-call in the assigned teams during the last interaction or those assigned to specific users (the latter only available only with Organizations).
* **View Snoozed Incidents:** Per default, we exclude snoozed incidents from this view. You can [adjust](/essentials/incident#include-snoozed-incidents) this setting, here.
* **Date Range:** Only show All Quiet incidents created within a certain date range. You can either select from our pre-configured options, such as "Last 7 Days" or choose custom dates if you are searching for an incident that occured during a specific timeframe.
* You can also [**Search in Incident Titles and Attributes**](/essentials/incident#text-search-for-incidents) to filter.

To filter any of these, click on the attribute you'd like to filter and choose what you'd like to filter for.

<img />

In this example, we are filtering for `Open` incidents with severity `Critical` from team `Test Team 1`:

<Tip>To delete all filters, simply click on the filter icon.</Tip>

<img />

### Text search for incidents

All Quiet allows you to do a text search for incidents in `title` and `attributes`. Just write what you're looking for in the text field `Search in title and attributes` and hit **ENTER** to see the resulting incidents.

<img />

### Filter for On-Call / Assigned Users

Use the "On-Call / Assigned Users" filter to display only incidents assigned to specific users (available only for Organizations) or incidents where certain users are currently on-call in the assigned teams based on the last interaction.

<Info>If an incident is assigned only to specific users and not to any team, it can only be accessed by the assigned users, users with [organization roles](/advanced/organizations#key-features-of-organizations), and the user who cretead the incident - if it's a [manually created incident](/essentials/incident#manually-create-an-incident).</Info>

### Include Snoozed Incidents

Per default, [snoozed incidents](/essentials/inbound#snoozing-inbound-integrations) are hidden. If you change the view from `Hide Snoozed` to `Include Snoozed` or `Only Snoozed`, the incident overview will display snoozed incidents as well / solely, identified by a Snooze symbol.
[Unsnooze](/essentials/incident#manually-snooze-%2F-unsnooze) the incident to inform your on-call colleagues about this incident.

<img />

## Compact List View (Reduced View of Incident List)

In addition to the default `Detailed List View`, you can also use our `Compact List View`.
The Compact List View is designed for fast scanning when you want to focus on the essentials and fit more incidents on the screen.

1. **How to switch**: Use the view toggle in the incident list header and select `Compact List View`. You can switch back anytime by selecting `Detailed List View`.
2. * **What you’ll see in Compact List View**: A condensed incident row with the most important identifiers and status information (for example incident name/title, current state/severity, and key timestamps/status indicators), optimized for quick overview. The order of the attributes shown depends on the order of the attributes in [Payload Mapping](/essentials/inbound#mapping-payloads).
   * **What you won’t see (vs. Detailed List View)**: Detailed per-incident context and extended fields that are available in Detailed List View view (such as expanded descriptions, additional metadata, and other secondary details) are hidden to keep the layout minimal. "Affected Services" are also only visible in the "Detailed List View"
3. **Actions**: Different to Detailed List View, in Compact List View, quick **actions per incident are directly available**. This makes the Compact List View especially useful for teams like NOC (Network Operations Center) teams that manage and distribute All Quiet incidents directly from the overview.

<img />

## Manually Create an Incident

Sometimes, your integrations are quiet, but you still find an incident.
That's why we added the option to manually create incidents.

1. Select `Incidents` in the sidebar of the Web App.
2. Click `Create Incident`.

<img />

<Tip>If you’re using All Quiet [Services and Status Pages](/advanced/status-pages), you can also create incidents manually from those menus, with the relevant Services already preselected.</Tip>

An overlay opens. It's time to add the All Quiet incident details.

1. Add a `Title`. This is the only mandatory attribute you need to add to create the incident.
2. Optionally, add a `Description`.
3. Select the `Status` of the incident.
4. Select the `Severity`.
5. Select one of your Organizations or "No organization". Depending on your selection, you will see the related Teams and Users below.
   <Info>Only visible for users of [organizations](/advanced/organizations).</Info>
6. If the incident directly [affects](/essentials/incident#affects-services) the functionality of one of your [services](/advanced/status-pages#services), you can flag this, here. <Info>Only visible for users of [status pages](/advanced/status-pages).</Info>
   1. When enabled, you may add a comment to further describe the incident.
   2. Optionally, you can share this comment with the subscribers of the status pages attached to your service.
   3. Use [**Affects Uptime**](/essentials/incident#affects-services) to control whether the incident counts toward downtime on your status pages. This option is **enabled by default** when you create an incident with affected services.
7. If you selected an Organization in step 5, you can assign the incident to one of your Organizations specific users and notify them, regardless if they are currently on-call or not. This is great if you need one specific person to be notified about an issue.
   <Info>Only available for users of [organizations](/advanced/organizations).</Info>
8. Select the `Team` you want to create the incident in. After creation, on-call team members will be notified.
   <Info>If the incident is created within an [organization](/advanced/organizations), you don't need to assign a team.</Info>
9. Based on the selected team, you can add an `Inbound Integration`. If it's a general incident that isn't realted to any integration, select `(No Integration)` or `All Quiet`.
10. Click `Create incident`.

<img />

After creation, the incident is added to the incidents overview and behaves exactly as the incidents that are automatically created from your [inbound integrations](/essentials/inbound). You can perform the same actions and workflows for both types of incidents.

<Tip> You can always interact with an incident that was created by you, even if it is later assigned to a Team that you usually don't have access to.</Tip>

<img />

## How to Change Incident Severity

Need to update the severity of an incident? It's quick and easy!

To get started, open the incident details or incident overview. You'll see the current severity displayed - just like in the image below, where an arrow points it out for you.

<img />

Click on the severity to open a handy overlay. Here, you can select a new severity for your incident. In this example, we're changing it from `Critical` to `Warning` (1). Once you've made your choice, simply save your changes (2).

<img />

After saving, you'll see the updated severity right in the incident details. Plus, every change is transparently tracked in the incident history - including who made the change - so your team always stays in the loop.

<img />

<Info>Keep in mind: Changing the severity of an incident can affect advanced routing, escalation flows, alerting, outbound integrations, and how incidents appear on your status pages. Make sure to consider these impacts when updating severity!</Info>

## Edit Incident Title

You can change an incident's title from the incident **details** page when you have permission.

1. Open the incident details.
2. Click the **pencil icon** next to the title.
3. Enter the new title and save.

<Note>Only **Organization Administrators**, **Organization Owners**, **Team Administrators**, and the user who **created** the incident can edit the title.</Note>

Title changes appear in the incident **[History](/essentials/incident#incident-history)** as an **Updated** event, showing the previous and new title — the same visual pattern as attribute changes from inbound payloads.

<Info>For [status page](/advanced/status-pages) users: Updated titles appear on affected status pages automatically — status pages read the current title from the incident.</Info>

<Info>If an incident was created from an [inbound integration](/essentials/inbound), subsequent webhook payloads **do not overwrite** a title you edited manually after creation. The mapped [`Title`](/essentials/inbound#reserved-and-required-attributes) attribute from payloads still applies when the incident is first created.</Info>

## Quick Actions

<img />

### Resolving

1. To resolve an open incident click the green `Resolve` button. This will notify all colleagues of the current escalation tier that the incident was resolved. Always **stops any auto-escalations**.

<Info>For [status page](/advanced/status-pages) users: If an incident is currently [affecting](/essentials/incident#affects-services) at least one service, resolving it will also automatically update the related services and status pages.</Info>

### Investigating

2. In case you've been notified of an open incident, and you can tell you're team that you're looking into the incident by clicking the blue `Investigate` button. This will notify all colleagues of the current escalation tiers that you're investigating the issue. It will also mark the incident as [acknowledged](/essentials/incident#history-acknowledged). Auto-escalations are stopped if your [settings](/essentials/escalations#automatic-escalation) say "Stop Auto-Escalation" if "Incident is acknowledged".

### Escalating

3. In case you need help from your colleagues, you can escalate the incident to the next escalation tier by clicking the red `Escalate` button. This will notify all colleagues of the current escalation tiers as well as the following escalation tier. This action **re-initiates / sustains** auto-escalations.

<Note>For Pro and Enterprise Users: If an **incident involves 2 or more teams**, escalations work slightly different. Using the "escalate" function escalates the incident in all currently involved teams.</Note>

## Action with Comment

In case you want to add a comment to your action, select `Comment`.

<img />

An overlay opens.

1. Select the Action you would like to perform.

<ul>
  <li><strong>Resolve:</strong> For more info, see section [Resolving](/essentials/incident#resolving).</li>
  <li><strong>Investigate:</strong> For more info, see section [Investigating](/essentials/incident#investigating).</li>
  <li><strong>Escalate:</strong> For more info, see section [Escalating](/essentials/incident#escalating).</li>
  <li><strong>Comment:</strong> Simply add a comment with context. Marks the incident as [acknowledged](/essentials/incident#history-acknowledged). Auto-escalations are stopped if your [settings](/essentials/escalations#automatic-escalation) say "Stop Auto-Escalation" if "Incident is acknowledged".</li>
  <li><strong>Reopen:</strong> Only visible if an incident is in state `resolved`. For more info, see section [Reopening Incidents](/essentials/incident#reopening-incidents).</li>
</ul>

2. Add your comment.
3. You can decide whether you want to publicly share the comment on your Status Pages.
   <Info>Only visible for users of [status pages](/advanced/status-pages) and if the incident is currently [affecting](/essentials/incident#affects-services) at least one Service.</Info>
4. Comment

<img />

Next, you will see the action plus the comment in your incident history.
<Info>For [status page](/advanced/status-pages) users: If your decided to share the comment publicly, we will add a litte `Public` flag.</Info>

<img />

### Edit Comments

You can edit existing comments from the incident **History** timeline when permitted.

1. In the **History** section, find the comment event.
2. Click the **pencil icon** on the comment.
3. Update the message and save.

<Note>Only the **comment author**, **Organization Administrators**, **Organization Owners**, and **Team Administrators** can edit a comment.</Note>

Edited comments show an **edited** marker. Hover the marker to see who last edited the comment and when.

<Info>For [status page](/advanced/status-pages) users: If a comment was shared publicly, edits appear on your status pages automatically.</Info>

## Advanced Actions

Special operations are forwarding (1), affecting (2), assigning (3), manually snoozing / unsnoozing (4) and archiving (5) incidents.

In the incident details view, these actions are available via the 3-dot-menu as well as some of them the additionally via the sidebar.

<img />

### Forwarding

You can manually `forward` single incidents to your team's [Outbound Integrations](/essentials/outbound). First, click "Forward".

<Tip>You will only see the `Forward` button if you activated the `Triggers Always After Forwarding / Triggers Only On Forwarding`  feature for at least one [Outbound Integration](/essentials/outbound). Else, we will automatically forward incidents to your outbound integrations. The setup can defined in each integration's details page.</Tip>

After clicking `Forward` in the incidents details view,

1. you can select the outbound integration you want to forward the issue to. Incidents can always be forwarded, even after they are resolved.
2. Click `Forward` to send the incident to the outbound integration.

<Info>In case they are still active, this action **does not** stop auto-escalations.</Info>

<img />

### Affects Services

<Note>Only visible for users of [status pages](/advanced/status-pages).</Note>

With the `Affects` action, you can easily connect incidents with your services and status pages, allowing you semlessly share downtime and incident updates with your customers, allowing you to fully focus on fixing the issue whilst having everyone onboard.

After clicking `Affects` in the incidents details view, an overlay opens.

1. Select the Services affected by the incident. The **affect action itself will always automatically update your services and status pages**, as it's only reason is to make sure incidents are shared with your customers.
2. **Affects Uptime** is **enabled by default**. You can disable it if you want to share the incident on status pages without it counting toward downtime.
3. In case you prepared [Message Templates](/advanced/status-pages#add-messagem-templates-to-service) for the affected service, you will find them here and can select them per click.
4. Optionally, you may add a comment. Here, we used the template.
5. You can decide whether you want to publicly share the comment on your Status Pages.
   <Tip> If you want to remove the connection between a Service and an Incident, simply open the `Affects Services` overlay in the respective incident, deselect the respective service and click `Save`. The incident will no longer show up on your status pages.</Tip>

<Info>In case they are still active, this action **does not** stop auto-escalations.</Info>

<img />

Next, you will see the action in your incident history.
If your decided to publicly share a comment, we will add a litte `Public` flag.

<img />

By marking the incident as affecting, it will also be diplayed on your [status pages](/advanced/status-pages).

1. See the incident that we marked as affecting for service `Cloud Infrastructure`.
2. The comment that we decided to share publicly.
3. Please note that the incident severity (Critical, Warning or Minor) also has an impact on how the incidents are displayed in the status graph. You can change the public description of the severity in the [public appearance section of your status page](/advanced/status-pages#public-appearance-of-status-page).

<img />

### Assign

<Note>Only available for users of Pro and Enterprise plans.</Note>
You can use the `Assign` action to assign an incident to teams, specific users, or both.

After clicking `Assign` in the incident's detail view, an overlay will open.

#### Assign to Team

Do you need help from an additional team to resolve an incident? Or do you want to reassign the incident to another team better suited to handle it?

1. After clicking the `Assign` button, you will see all teams in your [organization](/advanced/organizations). Select the teams you want to assign the incident to. You can either add teams to the currently assigned ones or reassign the incident to entirely different teams.
2. Select whether the Assign action should notify all assigned users and teams or only those that are newly assigned (default).
   <Note>When you add a new team, its on-call members are notified even if they were already notified through another assigned team. When assigning an incident to a team, All Quiet evaluates notification scope at the **team** level, not per user — so "Only those that are newly assigned" applies to teams (and their on-call members), not to whether an individual user has already received a notification.</Note>
3. Confirm with `Assign` to reassign the incident to the selected team(s). All involved on-call members of the all assigned teams will be notified about the incident.

<img />

On the incident details view

1. You can see the assign action in the history.
2. You can view which team(s) is/are currently in charge of the incident.
3. You can see the currently notified escalation tiers for each team.

<img />

<Note>Using "assign to teams" can have an impact on the team(s) auto-escalations. Learn more, [here](/essentials/escalations#impact-on-auto-escalations)</Note>

#### Assign to User

Need assistance from a specific colleague? No worries! With the `Assign to User` action, you can notify them anytime.

<Info>This part focuses on assigning an existing incident to a specific user. Want to create a **new incident** for a specific user? Learn [more](/essentials/incident#manually-create-an-incident).</Info>

1. Click the Assign button to view all users in your organization and select the user(s) you want to assign the incident to. You can either add them to the existing assigned teams and users or reassign the incident to different users entirely (see screenshot below).
2. Select whether the Assign action should notify all assigned users and teams or only those that are newly assigned (default).
3. Confirm with `Assign` to reassign the incident to the selected users(s). The selected user(s) will be notified about the inciden, no matter if they are on-call or not.

<img />

On the incident details view

1. You can see the assign action in the history. Note that the incident was assigned to one specific user and isn't assigned to any teams anymore.
2. You can view which users(s) is/are currently in charge of the incident. If the incident is assigned to several teams and / or users, all notified colleagues are listed, here.
3. Since only one user is now responsible, with no teams assigned, auto-escalations are halted.

<img />

<Tip>Of course, assign to user and assign to team can be combined.</Tip>

### Manually Snooze / Unsnooze

If you need time to investigate an incident and want to temporarily stop alerts, use the **Snooze** action to pause escalations.

You can snooze

1. for a pre-defined time
2. until a certain date and time
3. or indefinitely

<img />

The incident is automatically unsnoozed when the snooze window ends — the same outcome as clicking the Unsnooze button.

The **Unsnooze** button is available if you manually snoozed the incident or if [auto-snooze is enabled](/essentials/inbound#snoozing-inbound-integrations) for the integration and the incident is still within the snooze window.

Clicking Unsnooze (or reaching the end of the snooze window) triggers the following:

1. The incident is unsnoozed.
2. Current Tier members are notified.
3. The incident is marked as `not acknowledged`, and escalations either start (if snoozed via [integration settings](/essentials/inbound#snoozing-inbound-integrations)) or continue (if manually snoozed).

<img />

<h4>
  Snooze Similar Incidents
</h4>

<Note>Only **Team Administrators**, **Organization Administrators**, and **Organization Owners** can use this option. It appears only for incidents linked to an integration on a team you can manage.</Note>

When snoozing an incident, you can optionally create an automatic rule that snoozes future incidents matching the same conditions — so repeat alerts from the same source do not keep paging the team.

Open an incident from **Incidents** and use the **Snooze** action (available in the incident detail view and the incidents table). In the **Snooze Incident** dialog, enable **Snooze Similar Incidents**.

<img />

**How it works:**

1. Snoozes the current incident as usual (until a chosen date/time, or indefinitely).
2. When **Snooze Similar Incidents** is enabled, All Quiet also creates or updates a team routing named **Snooze Similar Incidents** with a new rule.
3. **Snooze Similar For (minutes)** sets how long future matching incidents stay snoozed. Leave empty or set to **0** for indefinitely. Quick duration buttons (30 min, 1 hour, etc.) update both the current snooze and the similar-incident duration when the toggle is on.
4. The rule targets **new incidents** from the same integration, prefilled with the current incident's attributes. You can refine attribute conditions, match type (all/any), weekly schedule windows, and one-time date restrictions before saving.
5. The use of this option creates a [routing](/advanced/routing) called **Snooze Similar Incidents** with the respective rule in the integration's root team, set to run before all other routings on the team. If the **Snooze Similar Incidents** routing already exists in the team, new rules will automatically be added to the same routing. Review or adjust rules anytime under [Advanced Incident Routing](/advanced/routing) > [Custom routing order](/advanced/routing#custom-routing-order).

<img />

<Tip>Reduce alert fatigue when the same noisy condition fires repeatedly — handle it once and automatically suppress similar incidents for a defined period.</Tip>

**Limitations:**

* Requires an incident with an integration.
* **Snooze similar** is available for a **single** incident at a time (not when multiple incidents are selected in bulk).

### Archiving

If you want to clean up your incidents overview, you can `archive` incidents. Archiving incidents does not change their resolution state, only moves them from the incidents overview to the archive.

1. `Archive` Intent
2. You can always open the archive via the three-dot-menu next to `Create Incident` on the incidents overview.

<Info>Archiving marks an incident as acknowledged and possibly stops auto-escalations, depending on your [settings](/essentials/escalations#automatic-escalation).</Info>

<img />

1. Archive view --> All archived incidents.
2. Archived incidents can always be `Unarchived`. Then, they will be visible on the incidents overview, again.

<img />

### Deleting Incidents

All Quiet automatically removes incidents after a retention period. In addition, administrators can permanently delete archived incidents before that date.

#### Automatic Deletion

Incidents are deleted automatically based on where they were created:

| Context                                                                          | Retention period                                                                                   |
| -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| **Standard plan** (incidents outside an [organization](/advanced/organizations)) | **6 months** after creation                                                                        |
| **Organization incidents** ([Pro and Enterprise](/advanced/organizations) plans) | **12 months** after creation                                                                       |
| **Enterprise** (custom agreement)                                                | **Custom** retention period possible — contact [support@allquiet.app](mailto:support@allquiet.app) |

The scheduled deletion date is shown for each incident in the **Properties** sidebar on the incident details page, so you can see when an incident will be removed.

<Info>Automatic deletion applies regardless of whether an incident is open, resolved, or archived.</Info>

#### Manual Deletion

<Note>Manual deletion is available to **Organization Owners**, **Organization Administrators**, and **Team Administrators** for incidents in teams they administer.</Note>

To permanently remove an incident before its scheduled deletion date:

1. [Archive](/essentials/incident#archiving) the incident.
2. Open the incident in the **details** view (the incident must be archived).
3. Use the **Delete** action (🗑️ trash bin icon next to the deletion date in the Properties sidebar).
4. Confirm the deletion in the confirmation modal.

<Warning>Deleting an incident is permanent. The incident and its history are removed and cannot be recovered. If you only want to hide an incident from the overview, solely [archive](/essentials/incident#archiving) it instead.</Warning>

## Reopening Incidents

Sometimes you need to re-open an incident that is already marked as resolved. You can simply do this by clicking the red `Reopen` button on a resolved incident.
You can also add a [comment](/essentials/incident#action-with-comment).

Reopening an incident will inform the current Tier 1 on-call users of the involved teams. It will also **restart the auto-escalations** of the involved team(s).

<Info>For [status page](/advanced/status-pages) users: If an incident is currently [affecting](/essentials/incident#affects-services) at least one service, reopening it will also automatically update the related services and status pages.</Info>

<img />

## Copy as Markdown

You can copy the **entire incident**, including its **events** (history and activity), as **Markdown**. That is useful when you want to paste a structured summary into internal documentation, a ticket, or run it through an **internal LLM** for analysis or drafting.

Open the incident’s **details** view and use the copy-to-Markdown action from there (see screenshot).

<img />

For automation or custom pipelines, you can also retrieve incident data through the [Public API](/advanced/api) instead of copying from the UI.

## Incident History

The "History" section in the incident details transparently shows you all details of the incident response.
It is split in 4 sections.

* Activity (1)
* On-Call Users (2)
* Teams (3)
* Whether the incident was already acknowledged or not (4)

<img />

### History - Activity

This section chronologically lists all events related to an incident, including updated values for attributes based on subsequent [inbound payloads](/essentials/inbound#the-payload-updated-an-existing-incident-and-no-notification-was-sent), [manual title changes](/essentials/incident#edit-incident-title), and [edited comments](/essentials/incident#edit-comments). It also shows the user, advanced routing rule or integration that created the event.

### History - On-Call

Shows all users that were on-call during the related event. The rotations, escalation tiers as well as any personal overrides that were active at the event are taken into account. If events happen during maintenance windows or while the integration is muted, we don't show any on-call users as nobody is notified.

### History - Teams

For each incident event, we list the teams and their specific escalation tiers that got notified about the event.

### History - Acknowledged

Shows the events that marked an incident as **acknowledged** or **not acknowledged**.

After an incident is `Created`, Tier 1 members are alerted and, if configured in your on-call schedule, auto-escalations start.

After somebody `Investigates`, `Comments`, `Snoozes`, `Archives` or `Resolves` an incident, is gets **marked as acknowledged**.
If your settings stop auto-escalations if [**incident is acknowledged**](/essentials/escalations#automatic-escalation), any potential auto-escalations are stopped. If your settings stop auto-escalations if [**incident is resolved**](/essentials/escalations#automatic-escalation), any potential auto-escalations are only stopped if somebody `Resolves` an incident.

For a previously acknowledged incident, `Escalating`, `Reopening`, `Unsnoozing` or `Assigning` it to a new / extra team / person **re-marks** the incident as **not acknowledged** and reactivates any potential auto-escalations.

The actions `Affects`, `Forward` and `Unarchive` have **no influence** on the current acknowledgement state and, therefore, on your auto-escalations.

## Incident Grouping

Are you experiencing a cascade of connected alerts for certain incidents that occur in your system? Our incident grouping feature helps cut through the noise, keeping your team focused on resolving the issue.
Easily consolidate multiple related incidents into a single event by matching key attributes, streamlining collaboration and speeding up resolution.

To enable this functionality, you must first configure grouping in the payload mapping section of your integration. Learn how to do this using `isGroupingKey` [here](/essentials/inbound#optional-additional-attribute-keys).

Once set up, incidents with matching values for the defined grouping key attributes will be grouped as long as the group is `Open`.

On the incident overview, grouped incidents can be identified by a little label that includes a count of the number of incidents grouped in this incident.

<img />

On the incident details view

1. You can view the overall status of the entire incident group. The group remains open until all incidents within it are resolved or until it is manually resolved.
2. Grouping is determined by the criteria set using `isGroupingKey` in the incident mapping of the integration. As long as the incident group remains `Open`, new subincidents matching the defined criteria (e.g., attribute `Group` = A) will be added to the group. After the group is `Resolved`, new incidents will create a new group and alert your teammates again.

   Exception: When using [groupingWindowInSeconds](/essentials/inbound#optional%2C-additional-attribute-keys), **new subincidents** (new `CorrelationId` values) are only added to an existing open group if they arrive within the defined window. After the window has ended, payloads with a **new** `CorrelationId` create a new group and may alert your on-call colleagues again — even if a previous group with the same grouping values is still `Open`. Payloads that match an **open subincident's** `CorrelationId` still **update or resolve** that subincident, the same as for incidents without grouping.
3. You can see all single incidents that are part of the group with their status & attributes. Subsequent payloads with the same `CorrelationId` update the subincident — including after the grouping window has expired — and any attribute changes are listed in this section.
   * **Special behavior for group incidents:**
     * New subincidents can only increase the group’s severity.
       * If the group is at `Warning` and a new subincident arrives with `Minor`, the group stays at `Warning`.
     * New subincidents never lower the group’s severity.
     * Existing subincidents can lower the group’s severity if they are updated later and all subincidents now have a lower severity than the group incident. Exception: The group severity was previously [set manually](/essentials/incident#how-to-change-incident-severity), or set by [routing rules](/advanced/routing#configure-actions).
4. The [history](/essentials/incident#incident-history) of the incident group. The first incident with a grouping attribute creates the group and starts auto-escalations. All collaboration takes part on group level, no seperate alerting for new incidents - this reduces the noise and keeps the focus on resolution. After the group is resolved, the next matching incidents will create a new incident group.

<img />

<Note>[Advanced Routing Rules](/advanced/routing) will always be applied, even if they are based on non-grouping attributes.</Note>
<Info>There's currently a limit of 128 subincidents per group.</Info>

<h2>
  Incident Details: Notification History
</h2>

<Note> The Incident Notification History is available to *Team Administrators*, *Organization Administrators* and *Organization Owners*.</Note>

The Incident Details view includes a **Notification History** overlay (modal) that shows **exactly which notifications were attempted/sent**, grouped by incident event, and broken down per user.

This is meant for:

* verifying who was notified,
* understanding why somebody did *not* receive a notification,
* troubleshooting delays, invalid recipients, rate limits, or discards.

The same administrators can open **[Outbound Integration Activity](#incident-details-outbound-integration-activity)** in the Properties sidebar to troubleshoot Slack, Jira, webhooks, and other outbound integrations for the incident.

### Where to Find it

Inside an incident’s details page, open the **Notification History** overlay via the **bell icon** in the top right corner.

<img />

### What the Overlay Shows

* **Grouped by incident event**: each group corresponds to a triggering event/intent with a timestamp.
* **Per-user breakdown**: for each affected user, it lists every notification attempt (channel + result).
* **Errors**: if a notification didn’t succeed and errors are present, they’re shown inline under the result.

The overlay uses the same status set as the personal notification logs. See **[Notification Result Glossary](/essentials/channels#notification-result-glossary)**.

<img />

<h3>
  Retention & Availability
</h3>

* **Retention**: notification logs are retained for **30 days** (same as [personal notification logs](/essentials/channels#notification-logs-retention-and-availability)).

<Note>**Enterprise** customers can agree on a **custom retention period** for notification logs as part of their deal — contact [support@allquiet.app](mailto:support@allquiet.app).</Note>

<h2>
  Incident Details: Outbound Integration Activity
</h2>

<Note>Outbound Integration Activity uses the same permissions as [Notification History](#incident-details-notification-history): **Organization Owners**, **Organization Administrators** (for the incident’s organization), and **Team Administrators** for any team tied to the incident. Regular team members and users without incident access do not see the control.</Note>

All Quiet records **outbound integration activity** for each incident: processing, webhooks, ticket and message updates, forwards, and chat interactions. This is **integration diagnostics**—not the incident’s main **[History](/essentials/incident#incident-history)** timeline (comments, assignments, and lifecycle events).

The same log records appear on each outbound integration’s **[Activity history](/essentials/outbound#outbound-history)** tab, scoped by integration instead of by incident.

### Where to Find it

On an incident’s **details** page, open the **Properties** sidebar. Next to the incident ID and other diagnostic actions, eligible users see a **webhook** icon labeled **Outbound Integration Activity**. This opens a modal titled **Outbound Integration Activity** (not a separate page tab).

<img />

### What the Modal Shows

Logs are **grouped by incident event** (each row in the incident timeline). For each group:

* **Intent badge** and **timestamp** of the incident event (for example Triggered, Acknowledged, Resolved).
* Under that, one row per log entry, with:
  * **Direction** — **Inbound** or **Outbound**
  * **Integration** — display name and type; links to that integration’s settings when known
  * **Processed** — when All Quiet recorded the log entry
  * **Operation** — see [Operations](/essentials/outbound#operations)
  * **Outcome** — see [Outcomes](/essentials/outbound#outcomes)
  * **Code** — short machine-oriented reason (especially for failures and skips)

Rows with extra detail can be **expanded** to show **Description**, **HTTP status** (when applicable), **Errors** (duplicate description lines are omitted), and **Payload details** (integration-specific context such as issue keys, channel IDs, or webhook URL and method).

If **Anonymize Outbound Logs** is enabled on the integration’s **Edit** tab (disabled by default), those entries are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept. See **[Outbound History](/essentials/outbound#outbound-history)**.

<img />

Up to **1,000** log entries per incident may be returned (newest first within each event group).

<h3>
  Retention & Availability
</h3>

* **Retention**: each log entry is kept for **14 days**, then removed automatically. See also [outbound activity log retention](/essentials/outbound#outbound-activity-logs-retention-and-filtering).

<Note>**Enterprise** customers can agree on a **custom retention period** for outbound integration activity logs as part of their deal — contact [support@allquiet.app](mailto:support@allquiet.app).</Note>

If nothing has been recorded yet, the modal shows: *“No outbound integration activity has been recorded for this incident yet.”*

<h2>
  Incident Details: Routing Rule Executions
</h2>

<Note>Routing Rule Executions are available to all users that have access to the incident.</Note>

All Quiet records **routing rule executions**: whenever advanced routing is evaluated for an incident, the system can log **which routing and rule** were involved, **what outcome** occurred (for example executed, delayed, or discarded), and a **snapshot** of the rule’s conditions, actions, and channels plus the **effect that actually applied** (teams, severity, discard, forwards, snooze, attributes, notification mute flags, and similar).

This is **routing engine diagnostics**. It is **not** the same as the incident’s main **History** timeline in the details view—that timeline is **[incident lifecycle events](/essentials/incident#incident-history)** (comments, assignments, status changes, and related activity). **Routing rule executions** and the routing editor’s **[Execution history](/advanced/routing#routing-execution-history-history-tab)** tab show the same underlying logs, scoped either **by incident** (here) or **by routing** (there).

### Where to Find it

Open an incident’s **details**, then the **Properties** sidebar. Use the **Routing rule executions** control (the same general area as [Notification History](/essentials/incident#incident-details-notification-history)).

<img />

### What the Modal Shows

Executions for **this incident** are listed **grouped by incident event** so you can relate routing runs to what changed on the timeline.

**Per group**

* **Incident event** context: **intent** (for example created, escalated) and **event time** when the group can be matched to an event.

**Per execution line**

* **Routing State** badge — **Executed**, **Delayed**, **Delay expired**, or other applicable [states](/advanced/routing#routing-states).
* **Routing › rule** names; if the rule still exists, you can **open that rule** in the routing editor.
* For delayed runs, **delay duration** (for example “delayed N minutes”) when applicable.
* **Execution time**.
* **Expand** for **Conditions**, **Actions**, **Channels**, and **Applied outcome** — the same panels as on the **routing execution history** tab ([expanded row details](/advanced/routing#expanded-row-details)).

If nothing has been recorded yet for this incident, the modal explains that no routing rule executions exist yet.

<img />

<h3>
  Retention & Availability
</h3>

* **Retention**: logs are kept for **30 days** from creation of each entry, then removed automatically.

<Note>**Enterprise** customers can agree on a **custom retention period** for routing rule execution logs as part of their deal — contact [support@allquiet.app](mailto:support@allquiet.app).</Note>

<h2>
  Incident Details: Call Logs
</h2>

<Note>Call Logs are available to all Team and Organization Administrators and Organization Owners that have access to an incident that was created from [Live Call Routing](/advanced/live-call-routing) — for example **Accepted** calls or **Voicemail** recordings. See [Incidents vs. call logs](/advanced/live-call-routing#incidents-vs-call-logs) for when a call creates an incident.</Note>

All Quiet links each qualifying inbound call to its incident. From the incident details page you can open the **call session** and its step-by-step **log timeline** without leaving the incident — the same data as on the Call Routing Number’s **[Call Logs](/advanced/live-call-routing#call-logs)** tab, scoped to this incident.

This is meant for:

* reviewing how the call was routed (welcome message, keypad choice, dial chain, accept attempts, voicemail),
* downloading the voicemail recording when one was captured,
* troubleshooting “what happened on the phone?” alongside the incident’s main **[History](/essentials/incident#incident-history)** timeline.

### Where to Find it

On an incident’s **details** page, open the **Properties** sidebar. Eligible incidents show a **phone** icon for **Call Logs** — in the same area as [Routing rule executions](/essentials/incident#incident-details-routing-rule-executions) and [Outbound Integration Activity](#incident-details-outbound-integration-activity).

<img />

### What the Modal Shows

The overlay opens the **call session** linked to this incident:

1. **Session summary** — caller number, **outcome** badge (**Accepted**, **Voicemail**, **Missed**, **Ongoing**, or **Failed**), start/end time, duration, and provider call ID.
2. **Voicemail** — download link when a recording was captured (same **365-day** retention as integration-level call logs).
3. **Detailed timeline** — chronological log entries for this call: dial chain resolution, each dial attempt, accept-call prompts, voicemail steps, and hang-up. See [Reading the log timeline](/advanced/live-call-routing#reading-the-log-timeline) for how to interpret **Step**, **Action**, and **Result** on each row.

<img />

<h3>
  Retention & Availability
</h3>

* **Retention**: detailed log entries and the call session summary are kept for **365 days**, then removed automatically.
* **Availability**: see [Live Call Routing — Call Logs](/advanced/live-call-routing#call-logs).

If no call session is linked to this incident, the **Call Logs** control is not shown.


# Outbound Integrations
Source: https://docs.allquiet.app/essentials/outbound

Connect your favorite notification tools to All Quiet

<Info> Only Team Administrators, Organization Administrators and Organization Owners have the permissions to create and edit Integrations. </Info>

All Quiet isn't just about managing incidents; it's about making sure your whole tech stack knows what's happening, in real-time. Our outbound integrations are the bridges between All Quiet and your favorite notification tools, ensuring nothing slips through the cracks.

## Built-in integrations

Send alerts from All Quiet to the tools you use. We have a generic outbound webhook integration as well as a growing list of pre-built integrations like [Slack](/integrations/outbound/slack) and more:

<CardGroup>
  <Card title="Confluence" icon="confluence" href="/integrations/outbound/confluence" />

  <Card title="Discord" icon="discord" href="/integrations/outbound/discord" />

  <Card title="GitHub" icon="github" href="/integrations/outbound/github" />

  <Card title="GitLab" icon="gitlab" href="/integrations/outbound/gitlab" />

  <Card title="Google Chat" icon="google" href="/integrations/outbound/google-chat" />

  <Card title="Google Docs" icon="google-drive" href="/integrations/outbound/google-docs" />

  <Card title="Google Sheets" icon="google-drive" href="/integrations/outbound/google-sheets" />

  <Card title="Jira" icon="jira" href="/integrations/outbound/jira" />

  <Card title="Linear" icon="timeline" href="/integrations/outbound/linear" />

  <Card title="Mattermost" icon="power-off" href="/integrations/outbound/mattermost" />

  <Card title="Microsoft Teams" icon="microsoft" href="/integrations/outbound/microsoft-teams" />

  <Card title="Notion" icon="n" href="/integrations/outbound/notion" />

  <Card title="Salesforce" icon="salesforce" href="/integrations/outbound/salesforce" />

  <Card title="ServiceNow" icon="user" href="/integrations/outbound/servicenow" />

  <Card title="Slack" icon="slack" href="/integrations/outbound/slack" />

  <Card title="Webhook" icon="webhook" href="/integrations/outbound/webhook" />

  <Card title="Zapier" icon="integral" href="/integrations/outbound/zapier" />
</CardGroup>

<h2>
  Troubleshooting: Outbound Integrations Never Fire
</h2>

If incidents look fine in All Quiet but **Slack, Jira, webhooks, or other outbound tools** never see updates, the outbound integration may still be configured correctly—**[advanced routing](/advanced/routing)** often decides what actually runs for each incident.

* Find **[routing rules](/advanced/routing)** whose **conditions match** the incident (after [payload mapping](/essentials/inbound#mapping-payloads)).
* Under **[Choose Channels](/advanced/routing#choos-channels)**, check **Mute all Integrations**, or rules that only enable a **subset** of outbound integrations (meaning others are muted by these rules).
* Under **[Configure Actions](/advanced/routing#configure-actions)**, check **`Discard`**, **snooze**, and other actions that suppress or delay outbound behavior.
* If your workflow depends on it, confirm the incident was **[forwarded](/essentials/incident#forwarding)** to the outbound integration.

For the full “no notification” checklist (including **snooze** and **mute** on the integration or team), see **[Inbound — New incident, no notification](/essentials/inbound#inbound-troubleshooting-no-notification)**.

When outbound tools still look silent but routing and mute settings look correct, inspect **[outbound integration activity logs](#outbound-integration-activity-logs)** on the integration or incident—especially **Skipped** and **Failed** outcomes, and whether routine skips were filtered (see [retention and filtering](#outbound-activity-logs-retention-and-filtering) below).

## Outbound Integration Activity Logs

<Note> Outbound Integration Activity logs are available to **Organization Owners**, **Organization Administrators** (for the integration’s organization), and **Team Administrators** of the team that owns the integration.</Note>

All Quiet records **activity history** for outbound integrations: each time an integration processes an incident, sends or receives webhooks, creates or updates tickets, messages, or documents, or handles user interactions (for example Slack buttons). These logs help administrators troubleshoot why an integration did or did not act on an incident.

Activity logs are **diagnostics-style** data (similar to [notification logs](/essentials/incident#incident-details-notification-history) on incidents and [routing rule execution logs](/advanced/routing#routing-execution-history-history-tab)), not a full audit trail for every team member. For organization-wide compliance logging, see **[Auditing](/advanced/auditing)**.

You can inspect the **same underlying log records** in two places, scoped either **by incident** ([Outbound Integration Activity](/essentials/incident#incident-details-outbound-integration-activity) in incident details) or **by integration** ([Outbound history](#outbound-history) on an outbound integration). Cross-links connect incident ↔ integration.

<h3>
  Retention and Filtering
</h3>

* **Retention**: each log entry is kept for **14 days**, then removed automatically.

<Note>On **Enterprise** plans, retention may differ if your organization agreed on a custom period — contact [support@allquiet.app](mailto:support@allquiet.app).</Note>

**What is not stored (by default):** Many routine **Skipped** outbound events are filtered out so history stays actionable—for example when an incident is snoozed, a routing rule mutes the channel, or configuration is missing. **Inbound** webhook logs are always kept.

### Operations

Operations saved in the Activity History are:

| Operation                               | Meaning                                                                                                     |
| --------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| **Process**                             | All Quiet ran the integration for this incident event (create or update ticket, post message, and similar). |
| **WebhookEvent**                        | Inbound webhook from the external system.                                                                   |
| **Interaction**                         | User interaction in the integration (for example a button or action in chat).                               |
| **IssueCreate** / **IssueUpdate**       | External issue or ticket created or updated.                                                                |
| **MessagePost** / **MessageUpdate**     | Chat message posted or updated.                                                                             |
| **DocumentCreate** / **DocumentUpdate** | Document or page created or updated.                                                                        |
| **Forward**                             | Incident forwarded to another integration.                                                                  |

### Outcomes

Operations saved in the Activity History are:

| Outcome       | Typical meaning                                                        |
| ------------- | ---------------------------------------------------------------------- |
| **Succeeded** | Action completed successfully.                                         |
| **Failed**    | Action failed—check description, HTTP status, and errors.              |
| **Skipped**   | Intentionally not run (for example preconditions, routing, or snooze). |
| **NoOp**      | Ran but made no effective change.                                      |
| **Discarded** | Event or action was discarded.                                         |

When present, expanded rows can show **payload details**: integration-specific identifiers (issue keys, channel IDs, repository names, webhook URL and method, and similar)—not full message bodies or secrets. Examples include Jira or Linear issue keys, Slack channel and message IDs, ServiceNow `sys_id`, and webhook URL or method for generic outbound webhooks.

On each integration’s **Edit** tab, you can enable **Anonymize Outbound Logs** (disabled by default). When enabled, new activity log entries for that integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept. This applies to both the integration **History** tab and the incident’s **[Outbound Integration Activity](/essentials/incident#incident-details-outbound-integration-activity)** view.

<h2>
  Outbound History
</h2>

<Note>Activity history is available to **Organization Owners**, **Organization Administrators** (for the integration’s organization), and **Team Administrators** of the team that owns the integration.</Note>

Go to **Integrations → Outbound** (1), open an integration (2), and select the **History** tab (3).

<img />

### What the Table Shows

A paginated table (**50 entries per page**, **Load more** for older entries), newest first:

| Column          | Content                                                                                                                                                             |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Processed**   | When the log entry was recorded.                                                                                                                                    |
| **Direction**   | **Inbound** (webhook received from the external system) or **Outbound** (request sent to the integration).                                                          |
| **Outcome**     | Succeeded, Failed, Skipped, and similar (see [Outcomes](#outcomes)).                                                                                                |
| **Operation**   | What happened (see [Operations](#operations)); **Code** is shown under the operation when present.                                                                  |
| **Description** | Human-readable summary. Empty when **Anonymize Outbound Logs** is enabled for the integration.                                                                      |
| **Action**      | **Intent badge** for the related incident event, when any.                                                                                                          |
| **Time**        | Timestamp of the related incident event.                                                                                                                            |
| **Incident**    | Short incident ID linking to incident details with **[Outbound Integration Activity](/essentials/incident#incident-details-outbound-integration-activity)** opened. |

<img />

If nothing has been recorded yet, the empty state explains that no activity exists yet, plus the availability and retention note above.

<h3>
  Troubleshooting With Activity History
</h3>

* **No logs for expected skips** — Snoozed incidents, routing mutes, missing credentials or channels, and similar **Skipped** outcomes are often **not persisted** unless **Debug mode** is on for that integration.
* **Missing descriptions or payload details** — If **Anonymize Outbound Logs** is enabled on the integration’s **Edit** tab, new entries are stored without descriptions, external identifiers, error details, and payload data.
* **Inbound vs outbound** — **Inbound** rows explain webhooks *from* Slack, Jira, and similar; **Outbound** rows explain calls *to* those systems.
* **Not ServiceNow API debug** — [ServiceNow](/integrations/outbound/servicenow) integrations may expose a separate admin **API debug** view; that is distinct from this general outbound activity history.

## Propose a new integration

Didn't find your tool here? Reach out to [support@allquiet.app](mailto:support@allquiet.app) and let us know your preferred integration. We're always happy to grow our integrations list.


# Teams
Source: https://docs.allquiet.app/essentials/teams

Modern teams are at the heart of All Quiet

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

* Each user can be a member of multiple teams.
* Each integration is connected to exactly one (root) team.
* Each incident triggered by an integration is thus per default available for collaboration to the members of the integration's team. Within [Organizations](/advanced/organizations), collaboration across multiple teams is possible.

## Create a team

<Info>New Teams can be created by Users who signed up without being invited, as well as Billable Users, *Organization Administrators* and *Organization Owners*.<br />This documentation explains team creation without an Organization. Check out our doc for [Organizations](/advanced/organizations#creating-a-new-team-in-your-organization) to learn more about the team creation within an Organization.</Info>

<Steps>
  <Step title="Step 1">
    Under `Teams` click `Create Team`.

    <img />
  </Step>

  <Step title="Step 2">
    1. Enter a `Diplay Name` for your team.
    2. Optionally, you can enter a timezone. Per default, we select your browser's timezone.
    3. For Pro and Enterprise plans: Select the [Organization](/advanced/organizations) you want to add the team to, or select "No organization".
    4. Decide if you want to be included in the standard escalation policy.
    5. Optionally, you can add `Labels`. This is handy if you want to organizae your teams into categories, e.g. departments or business units. You can use the labels to filter [incidents](/essentials/incident#filtering-incidents), integrations and your [team overview](/essentials/teams#team-overview).
    6. Hit `Create Team`. You can later change these settings.

    <img />
  </Step>
</Steps>

After creating your team, you’ll have several options to manage it. Let’s explore them below.

<img />

## Edit Team

1. In the `Edit` tab, you can configure the general settings for your team.
2. This includes your team's `Display Name`
3. Adjust your team's `Timezone`. The timezone is used for your teams calendar, schedules and escalations. Per default, it's UTC.
4. For Pro and Enterprise plans: Select the [Organization](/advanced/organizations) you want to add the team to, or select "No organization".
5. You can add or remove `Labels`. This is handy if you want to organize your teams into categories, e.g. departments or business units. They are combined with [inbound integration labels](/essentials/inbound#edit-your-integration’s-general-settings) when [filtering incidents](/essentials/incident#filtering-incidents). You can also the team labels to filter integrations and your [team overview](/essentials/teams#team-overview).
6. Schedule delivery of your team' weekly [Engagement Report](/advanced/report#engagement-report).
7. You can edit the billable user of your team. If your team is part of an [organization](/advanced/organizations), this field will not be available, as the team will be billed through the organization's billable user.
8. Make sure to `Save` your changes.

<img />

## Members

### Roles

A user has one of the following roles within a team:

* `Member`: A member can collaborate on all incidents, view the team calendar, get an engagement report and create their own personal overrides.
* `Administrator`: An admin can additionally set up the escalation schedules, create overrides for the whole team and create and manage all of the team's integrations plus the respective advanced routing in the team. Also, they can manage the team's users and, [if applicable, the billable user](/miscellaneous/billing#how-to-change-the-billable-user).

### Inviting Members

After setting up your team, you're instantly assigned the `Administrator` role and become the primary account holder for billing purposes. Refer to our [Billing](/miscellaneous/billing) section for more details.

Inviting colleagues is straightforward:

* Simply send them an invite via email.
* They'll need to sign up and accept your invitation to collaborate.

This process ensures a secure and efficient team collaboration setup.

<Steps>
  <Step title="Step 1">
    Navigate to the `Members` section within your team settings.

    <img />
  </Step>

  <Step title="Step 2">
    Click "Invite New".

    <img />
  </Step>

  <Step title="Step 3">
    <ul>
      <li>1. Choose the Role that the new team members should receive. Select between [`Member` and `Administrator`](/essentials/teams#roles).</li>
      <li>2. Simply add Users from your [Organization](/advanced/organizations) or enter the email addresses of colleagues you wish to invite.</li>
      <li> 3. Click `Invite`. An invitation email will be sent to each with further instructions.</li>
    </ul>

    <img />
  </Step>

  <Step title="Step 4">
    Invitees receive an email with a link to `Accept Invitation to [Team Name]`. Clicking this confirms their membership and grants access to collaborate.

    <img />
  </Step>
</Steps>

## Schedules & Escalations

* To learn more about **team schedules**, follow this [link](/essentials/escalations#schedules).

* To learn more about **team escalations**, follow this [link](/essentials/escalations#escalation-tiers).

* For more information about **escalating an incident to additional teams** or **reassigning an incident to a different team**, follow this link [link](/essentials/escalations#auto-escalations-across-several-teams).

## Team Overrides

Team Administrators can manage on-call coverage changes for any team member from `Team > Overrides`. This includes creating offline and online overrides and assigning covering users for offline members.

To learn more about **team overrides**, follow this [link](/essentials/escalations#team-member-overrides).

## Maintenance Mode

The maintenance mode feature for teams allows for the management of incident alerts during times of scheduled maintenance or expected downtime. It is accessible through the `Team > Maintenance` page in the All Quiet Web App.

You can either

1. Create new maintenance window.
2. Edit planned maintenances.

<img />

The maintenance schedule, once created, is also visible in the team's calendar, offering insight into planned maintenance or downtime.

When creating a new maintenance window, you can configure the following elements:

<Steps>
  <Step title="Quick Actions">
    Use these to quickly populate the start and end times with predetermined durations ranging from 30 minutes to 8 hours.
  </Step>

  <Step title="Start Date and Time">
    Specify the start date and time for the maintenance window according to the team's timezone.
  </Step>

  <Step title="End Date and Time">
    Specify the end date and time to mark the conclusion of the maintenance window.
  </Step>

  <Step title="Type">
    Choose between two types of maintenance modes:

    <ul>
      <li><strong>Maintenance:</strong> Selecting this option will prevent the creation of new incidents during the scheduled period.</li>
      <li><strong>Muted:</strong> This option allows incidents to be created without sending out any notifications during the period.</li>
    </ul>
  </Step>

  <Step title="Create">
    Clicking the `Create` button will confirm and activate the maintenance schedule. It will also be displayed in the team's calendar.
  </Step>
</Steps>

<img />

## Calendar

To learn more about **team calendars**, follow this [link](/essentials/escalations#team-calendar).

## Incident Report

To learn more about your Incident KPIs, check our your [Team's Incident Report](/advanced/report#incident-report).
You can also find the [Engagement Report](/advanced/report#engagement-report) on this tab.

## Team Overview

The team overview show all the teams you have a [team role](/essentials/teams#roles) in or, if you're a billable user, that are biiled by you.
For users wit [organization roles](/advanced/organizations#key-features-of-organizations), it also shows teams of your organization that you don't have an explicit role in.

Therefore, filtering this view via team labels or team names can be handy for people with a higher number of teams.

<img />


# Welcome to All Quiet!
Source: https://docs.allquiet.app/index

Incident Escalation, Reinvented.

<img />

## What is All Quiet?

All Quiet reinvents on-call and alerting, enabling tech teams to address IT incidents with reliability and speed. Seamlessly integrate your observability tools with All Quiet to enhance incident management and use our extensive integrations for a streamlined workflow.

* **For modern teams:** Tailored for world's leading tech teams taking active responsibility for software systems, enhancing efficiency and response times.
* **Integrated with modern stack:** Dozens of inbound (think Datadog) and outbound (think Slack) [integrations](/integrations/overview). Plus, [native mobile apps](https://allquiet.app/download-app) for iOS & Android keep incidents at your fingertips in a dedicated channel.
* **Advanced On-Call:** Our on-call calendar simplifies rotation setup, escalation policy creation, and override management, all while being the most user-friendly in the market.

All Quiet is not just lightweight but deeply customizable, meeting modern team needs with features like [advanced incident routing](/advanced/routing).

Get up & running with All Quiet for your team in **under 15 minutes** — including team invites, integration setup, and your first incident. Check our [Quickstart Guide](/quickstart) to get started.

## Updates

All Quiet is rapidly evolving. Stay informed with our [Changelog](https://allquiet.app/changelog). We are recommending to subscribe to our RSS Feed.

## Get in touch

Got feedback, requests, or suggestions? We’re all ears. Email us at [support@allquiet.app](mailto:support@allquiet.app) or [book a demo](https://meetings-eu1.hubspot.com/nkoeppl/allquiet-product-demo). We'd love to get to know you.


# Linear Overview
Source: https://docs.allquiet.app/integrations/common/linear

Do you want to use Linear for Inbound or Outbound?

To send incidents from All Quiet to your team's Linear board, check out our [Linear Outbound Integration](/integrations/outbound/linear) documentation.

After setting up your [Linear Outbound Integration](/integrations/outbound/linear), you will be able to create new incidents in All Quiet creating [Linear Issues](/integrations/outbound/linear#create-all-quiet-incidents-from-linear).


# Mattermost Overview
Source: https://docs.allquiet.app/integrations/common/mattermost

Do you want to use Mattermost for Inbound or Outbound?

To send incidents from All Quiet to your team's Mattermost channels, check out our [Mattermost Outbound Integration](/integrations/outbound/mattermost) documentation.

After setting up your [Mattermost Outbound Integration](/integrations/outbound/mattermost), you will be able to create new incidents in All Quiet using [a custom Mattermost command](/integrations/outbound/mattermost#create-incidents-from-mattermost).


# Microsoft Teams Overview
Source: https://docs.allquiet.app/integrations/common/microsoft-teams

Do you want to use Microsoft for Inbound or Outbound?

To send incidents from All Quiet to your MS Teams channels, check out our [MS Teams Outbound Integration](/integrations/outbound/microsoft-teams) documentation.

After setting up your [MS Teams Outbound Integration](/integrations/outbound/microsoft-teams), you will be able to create new incidents in All Quiet using [MS Teams command](/integrations/inbound/microsoft-teams) `@All Quiet incident`.


# Slack Overview
Source: https://docs.allquiet.app/integrations/common/slack

Do you want to use Slack for Inbound or Outbound?

To send incidents from All Quiet to your team's Slack channels, check out our [Slack Outbound Integration](/integrations/outbound/slack) documentation.

After setting up your [Slack Outbound Integration](/integrations/outbound/slack), you will be able to create new incidents in All Quiet using [Slack command](/integrations/inbound/slack) `/aq new`.


# Webhook Overview
Source: https://docs.allquiet.app/integrations/common/webhook

Do you want to use Webhooks for Inbound or Outbound?

To create new incidents in All Quiet using webhooks, check out our [Webhook Inbound Integration](/integrations/inbound/webhook) documentation.

To send incidents from All Quiet to any third-party platform using webhooks, check out our [Webhook Outbound Integration](/integrations/outbound/webhook) documentation.


# Zapier Overview
Source: https://docs.allquiet.app/integrations/common/zapier

Do you want to use Zapier for Inbound or Outbound?

To create Triggers in Zapier to send incidents from All Quiet to any other app, check our [Zapier Outbound Integration](/integrations/outbound/zapier) documentation.

After setting up your [Zapier Outbound Integration](/integrations/outbound/zapier), you will be able to create new incidents in All Quiet using Zapier Actions, following our [Zapier Inbound Integration](/integrations/inbound/zapier) documentation.


# AppDynamics
Source: https://docs.allquiet.app/integrations/inbound/appdynamics

Connect AppDynamics to All Quiet

<Info>Setup time: 3 Min</Info>

Integrate AppDynamics into All Quiet by using our custom integration.

## 1. Add AppDynamics Integration to Your All Quiet Team

### Create an AppDynamics integration

1. Click on the `Inbound Integrations` Tab.
2. Click on `+ Create`.

<img />

### Select AppDynamics as the Integration's Type

1. Enter a `Display Name` for your AppDynamics integration, e.g. "AppDynamics".
2. Pick the `Team` you'd like to add the integration to.
3. Select `AppDynamics` as the type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet webhook URL

After creating the integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on AppDynamics.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Create a custom integration on AppDynamics

Sign in to your AppDynamics Account.

1. Open `Account Overview`
2. `Launch Controller`.

<img />

Select `Alert & Respond` page.

<img />

1. Open `HTTP Request Templates` in sitenav.
2. Start `New` template.

<img />

It's time to define the template.

1. Add a `Name` for your HTTP request template, like "All Quiet"
2. For the `Request URL`, select `Method` "Post"
3. As `Raw URL`, paste in the All Quiet webhook URL you've obtained in step [Get The All Quiet Webhook URL](/integrations/inbound/appdynamics#get-the-all-quiet-webhook-url).

<img />

1. As `Authentification` `Type`, select "NONE"
2. As `Payload` `MIME Type`, select "application/json"
3. Use the following `Payload`

```
{
  "deepLink": "${latestEvent.deepLink}",
  "eventName": "${latestEvent.displayName}",
  "summary": "${latestEvent.summaryMessage}",
  "eventID": "${latestEvent.id}",
  "guid": "${latestEvent.guid}",
  "eventType": "${latestEvent.eventType}",
  "eventTypeKey": "${latestEvent.eventTypeKey}",
  "applicationName": "${latestEvent.application.name}",
  "nodeName": "${latestEvent.node.name}",
  "message": "${latestEvent.eventMessage}",
  "severity": "${topSeverity}"
#if(${latestEvent.healthRuleEvent} == true)
,
  "healthRuleId": "${latestEvent.healthRule.id}",
  "healthRuleName": "${latestEvent.healthRule.name}",
  "incidentId": "${latestEvent.incident.id}",
  "incidentName": "${latestEvent.incident.name}"
#end
}
```

<img />

1. In section `Response Handling Criteria`, add `Success Criteria` with `Status Code` 200 and `Content Type` "application/json".
2. In `Settings`, check `One Request Per Event` box.
3. Click on `Save`.

<img />

To test the configuration, return to the template and click on `Test`.

<img />

For the test, you can choose between different `Log Level` and `Criteria`.

1. Select a `Log Level`, like "Debug".
2. Select an `Event Type Trigger`. Here, we chose "Health Rule Violation Started - Warning". This means we expect a new All Quiet Incident with Severity "Warning" when running the test.
3. `Run Test`.

<img />

After running the test, you'll receive a notification if the test run was successful.

<img />

To check if the expected All Quiet Incident was created, open our Web App and navigate to /app/incidents.

<img />

<Check>AppDynamics is now successfully integrated with All Quiet.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/AppDynamics.tf) the default mapping of the `allquiet_integration_mapping` resource for the AppDynamics integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# AppSignal
Source: https://docs.allquiet.app/integrations/inbound/appsignal

Connect AppSignal with All Quiet

<Info>Setup time: 2 Min</Info>

Integrate AppSignal to send alerts and errors to All Quiet by using our custom integration.

## 1. Add AppSignal Integration to Your All Quiet Team

### Create a AppSignal integration

1. Click on the `Intbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select AppSignal as the Integration's Type

1. Enter a `Display Name` for your integration, e.g. "AppSignal".
2. Pick the `Team` you'd like to add the integration to.
3. Select `AppSignal` as the type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet webhook URL

After creating the integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on AppSignal.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Create a custom integration on AppSignal

Sign in to your AppSignal Account.

1. Open `Applications`
2. Select the application you want to add the All Quiet integration to, here `My Application`.

<img />

In the navigation bar, select `App settings`.

<img />

1. In the app settings, select `Notifications > Notifiers` in the navigation bar.
2. On the `Notifiers` page, select `Add integration +`.
3. Connect All Quiet via `Webhook`.

<img />

Now, it's time to set up the Webhook.

1. Select a `Name` for the Webhook, e.g. `All Quiet`.
2. Select for which events your would like to send notifications.
   <Info> As of now, we support event types `Alerts` and `Errors (Exception Incidents).`</Info>
   Here, we select both types we support.
3. As `Webhook url`, paste in the All Quiet webhook URL you've obtained in step [Get The All Quiet Webhook URL](/integrations/inbound/appsignal#get-the-all-quiet-webhook-url).
4. Click `Submit`.

<img />

Afterwards, click `Test Webhook` to see if you can send a payload to All Quiet.

<img />

<Check>All Quiet will now create incidents based on AppSignal Errors.</Check>

## Create All Quiet Incidents based on AppSignal Uptime Monitoring & Anomaly Detection Alerts

To forward alerts from AppSignal Uptime Monitoring and Anomaly Detection to All Quiet, you have to add All Quiet as Notifier. Here is how:

### Uptime Monitoring

1. Select `Uptime Monitoring` in your application's navigation bar.
2. Then, `Edit uptime monitor`

<img />

1. Add All Quiet webhook in `Notify me through` section.
2. Click `Update uptime monitor`

<img />

<Check>All Quiet will now create incidents based on AppSignal uptime monitoring.</Check>

### Anomaly Detection

1. Select `Anomaly Detection > Triggers` in your application's navigation bar.
2. Then, click `Add a trigger` or edit an existing one.

<img />

1. Add All Quiet webhook in `Notify me through` section.
2. Click `Save trigger`

<img />

<Check>All Quiet will now create incidents based on AppSignal anomaly detection.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/AppSignal.tf) the default mapping of the `allquiet_integration_mapping` resource for the AppSignal integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# AWS
Source: https://docs.allquiet.app/integrations/inbound/aws

Connect Your AWS Amazon CloudWatch alerts to All Quiet

<Info>Setup time: 4 Min</Info>

Connect AWS Amazon CloudWatch to All Quiet for enhanced alert management and efficient incident response.

## 1. Create Your AWS Amazon CloudWatch Integration on All Quiet

Login into your All Quiet account.

### Create AWS Amazon CloudWatch Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "AWS CloudWatch".
2. Select a `Team`.
3. Select `AWS Amazon CloudWatch` as the type.
4. Click `Create Inbound Integration`.

<img />

### Copy Webhook URL

1. Now that you've successfully created your AWS Amazon CloudWatch Integration, make sure to copy the webhook URL for later.
2. AWS SNS requires HTTPS subscriptions ("Webhooks") to be confirmed by the subscriber. This is done by visiting a subscription URL which AWS sends to the webhook in a payload. All Quiet automatically confirms this URL. When you've just created your AWS Amazon CloudWatch Integration the confirmation status will be **pending**.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Set up Your AWS CloudWatch Alarms

Login into your AWS console.

### Create SNS Topic

1. In the AWS "Simple Notification Service" (SNS) section, navigate to "Topics".
2. Click on "Create topic" to create a new topic which will be used as a destination for your CloudWatch alarms.

<img />

1. Select "Standard" as the topic type.
2. Choose a name for your new topic, e.g. "AllQuiet-CloudWatch-Topic".
3. Click "Create topic" to create a topic.

<img />

### Create SNS HTTPS Subscription

Now that you've created a topic, you need to create a subscription to this topic. Click "Create subscription".

<img />

1. Select "HTTPS" as the protocol of your new subscription.
2. Paste the Webhook URL that you've copied in step [Copy Webhook URL](/integrations/inbound/aws#copy-webhook-url).
3. Click "Create subscription".

<img />

Navigate back to you All Quiet Integration that you've created. In the integration `Settings`, it should show that the subscription has been confirmed successfully.

<img />

### Configure AWS CloudWatch Alarms

Navigate to CloudWatch > Alarms in your AWS console.

1. Choose "Select an existing SNS topic" when creating or editing your AWS CloudWatch alarms.
2. Choose the SNS topic that you've created before.

<img />

## 3. Test Your AWS Amazon CloudWatch Integration

You're almost done. 🥳 The next steps are merely there to verify if everything's setup correctly!

Navigate to the payload mapping of your AWS Amazon CloudWatch integration.

1. Click `Reload button` to load your latest payloads.
2. Select the latest payload from your alarm. Be aware that the very first payload Amazon SNS will send you is the subscription confirmation message. This payload won't map correctly to All Quiet's incidents. If you haven't received a payload from a real alarm yet, you can use the default example payload that is prefilled.
3. You can see how the mapping will transform this AWS Amazon CloudWatch payload to an All Quiet incident.

<img />

<Check>Your AWS Amazon CloudWatch is now successfully integrated with All Quiet, enhancing your incident management capabilities.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/AmazonCloudWatch.tf) the default mapping of the `allquiet_integration_mapping` resource for the AWS Cloudwatch integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Azure
Source: https://docs.allquiet.app/integrations/inbound/azure

Connect Your Microsoft Azure Monitor to All Quiet

<Info>Setup time: 5 Min</Info>

Connect your Microsoft Azure Monitor to All Quiet for enhanced alert management and efficient incident response.

## 1. Create Your Microsoft Azure Monitor Integration on All Quiet

Login into your All Quiet account.

### Create Microsoft Azure Monitor Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Azure".
2. Select a `Team`.
3. Select `Azure Monitor` as the type.
4. Click `Create Inbound Integration`.

<img />

### Copy Webhook URL

Now that you've successfully created your Microsoft Azure Monitor Integration, ensure you copy the webhook URL for use later when setting up your Azure Action Group.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Setup Your Azure Monitor

Login into your Microsoft Azure portal.

### Create Action Group

1. Navigate to Azure services > Monitor
2. Click on `Alerts`
3. Click on \`Action groups to manage your action groups within Azure Monitor.

<img />

Click `+ Create` to create a new action group.
You can also utilize one of your existing action groups to configure a webhook action for 'All Quiet'.

<img />

1. Navigate to the Basics tab of the Create action group section.
2. Under Project details, select a Resource group.
3. Choose a Region from the dropdown.
4. In the Instance details section, enter a name for the Action group name.
5. Provide a Display name for the action group.
6. Click on the Actions tab to proceed to the next step.

<img />

### Configure Actions

1. Navigate to the Actions tab.
2. Select the Action type dropdown and choose Webhook.
3. Provide a name for the action in the Name field, for example, "All Quiet".
4. Click on the edit button (represented by a pencil icon) to configure the webhook settings.

<img />

1. Enter your Webhook URL in the URL field that you've created in [Copy Webhook URL](/integrations/inbound/azure#copy-webhook-url).
2. Enable the common alert schema by selecting Yes.
3. Click the OK button to confirm and close the popup.
4. After configuring, proceed by clicking the Review + create button to finalize the action group creation.

<img />

## 3. Test Your Microsoft Azure Monitor Integration

You're almost done. 🥳 The next steps are merely there to verify if everything's setup correctly!

1. After creating the Action Group, you'll be redirected to the list of action groups. Choose the action group you just created.
2. Click on "Test action group".
3. In the right pane, choose a sample type, such as "Metric alert - Dynamic Threshold".
4. Select the webhook action you created, as mentioned in [Create Action Group](/integrations/inbound/azure#create-action-group).
5. Click "Test".

<img />

Navigate to the payload mapping of your Azure Monitor integration.

1. Click `Reload button` to load your latest payloads.
2. Select the latest payload you received from Azure. If you haven't received a payload from a real alarm yet, you can use the default example payload that is prefilled.
3. Observe how the mapping transforms the Microsoft Azure Monitor payload into an All Quiet incident.

<img />

<Check> Microsoft Azure Monitor is now successfully integrated with All Quiet, enhancing your incident management capabilities.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/AzureMonitor.tf) the default mapping of the `allquiet_integration_mapping` resource for the Azure integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Checkly
Source: https://docs.allquiet.app/integrations/inbound/checkly

Connect Checkly Monitoring with All Quiet

<Info>Setup time: 3 Min</Info>

Integrate Checkly with All Quiet in a matter of minutes. With webhooks, you can automatically send alerts from your Checkly monitoring directly to All Quiet, streamlining your team's incident management process.

## 1. Create Checkly Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Checkly as the integration's type

1. Enter a `Display Name` for your integration, e.g. "Checkly".
2. Select a `Team`.
3. Select `Checkly` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Copy Webhook URL

After creating the integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on Checkly.

If you choose to add a webhook secret in Checkly for increased security, you’ll need to add it here later.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure a custom integration with Checkly

Once you've set up an integration of type "Checkly" with All Quiet, the next crucial steps involve configuring your Checkly alerts. This is essential for ensuring that your monitoring setup can effectively send incidents to the All Quiet webhook.

First, you need to sign in to your Checkly Account.

1. Open `Alerts`
2. Click `Add more channels`

<img />

Select `Webhook` as the channel type.

<img />

Now, it's time to set up the webhook.

1. Select a name for the webhook, e.g. `All Quiet`.
2. Method should be `POST` as we want to forward alerts to All Quiet.
3. As URL, paste in the All Quiet webhook URL you've obtained in step [Get The All Quiet Webhook URL](/integrations/inbound/checkly#copy-webhook-url).
4. For extra security, you can select the tab `Webhook secret` and generate a webhook secret.

<img />

If generated, copy the secret.

<img />

Open your All Quiet Checkly integration settings in a second tab.

1. Paste the webhook secret.
2. `Save Webhook Secret Settings`

<img />

Return to your webhook configuration in Checkly and open the `BODY` tab.
Paste the following payload into your checkly webhook template.

```
{
"CHECK_NAME" : "{{CHECK_NAME}}",
"CHECK_ID" : "{{CHECK_ID}}",
"CHECK_TYPE" : "{{CHECK_TYPE}}",
"GROUP_NAME" : "{{GROUP_NAME}}",
"ALERT_TITLE" : "{{ALERT_TITLE}}",
"ALERT_TYPE" : "{{ALERT_TYPE}}",
"CHECK_RESULT_ID" : "{{CHECK_RESULT_ID}}",
"RESPONSE_TIME" : "{{RESPONSE_TIME}}",
"API_CHECK_RESPONSE_STATUS_CODE" : "{{API_CHECK_RESPONSE_STATUS_CODE}}",
"API_CHECK_RESPONSE_STATUS_TEXT" : "{{API_CHECK_RESPONSE_STATUS_TEXT}}",
"RUN_LOCATION" : "{{RUN_LOCATION}}",
"RESULT_LINK" : "{{RESULT_LINK}}",
"SSL_DAYS_REMAINING" : "{{SSL_DAYS_REMAINING}}",
"SSL_CHECK_DOMAIN" : "{{SSL_CHECK_DOMAIN}}",
"STARTED_AT" : "{{STARTED_AT}}",
"TAGS" : "{{TAGS}}"
}
```

<img />

Scroll down further.

1. Select the type of `Notification Events` for which you would like to create All Quiet alerts.
2. Activate `Subscriptions` if you want to make sure that alerts for newly created checks will also be sent to All Quiet.

<img />

Scroll back up to the top of the page.

1. Test the Webhook. If successful, you will find the generated incident on your All Quiet incident overview (see 2nd screenshot).
2. Save the webhook.

<img />

Checkly incident in All Quiet

<img />

<Check> You're ready to go. If you set up your integration this way, Checkly will send alerts for all of your checks to All Quiet.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Checkly.tf) the default mapping of the `allquiet_integration_mapping` resource for the Checkly integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Coralogix
Source: https://docs.allquiet.app/integrations/inbound/coralogix

Connect Coralogix with All Quiet

<Info>Setup time: 5 Min</Info>

Integrate Coralogix with All Quiet in a matter of minutes. With webhooks, you can automatically send alerts from Coralogix directly to All Quiet, streamlining your team's incident management process.

## 1. Create Coralogix Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Dash0 as the integration's type

1. Enter a `Display Name` for your integration, e.g. "Coralogix".
2. Select a `Team`.
3. Select `Coralogix` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet Webhook URL

After creating the integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on Coralogix.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure the Integration with Coralogix

Once you've set up an integration of type "Coralogix" with All Quiet, it takes only a few more steps in your Coralogix account to finish off your setup.

### Add a Webhook Integration

From your dashboard in Coralogix, select

1. `Integrations`
2. `Webhooks`

<img />

Next, select `Generic Webhook` as integration.

<img />

On the next screen, click `Add New`.

<img />

#### Configure the Webhook to All Quiet

Before you can save the webhook integration, you need to configure it.

On the `Settings` screen

1. Add a `Webhook Name`, e.g "All Quiet Webhook".
2. As As `URL`, paste in the All Quiet Webhook URL you've obtained in step [Get the All Quiet Webhook URL](/integrations/inbound/coralogix#get-the-all-quiet-webhook-url).
3. The `UUID` is filled by default.
4. As `Method`, select "Post".
5. Click `Next`.

<img />

Now it's type to fill the message.

1. As `Headers`, paste

```json Headers theme={null}
{
  "Content-Type": "application/json"
}
```

2. As `Body`, paste

```json Body theme={null}
{
  "resolved_aware_dedup_key": "$RESOLVED_AWARE_DEDUP_KEY",
  "alert_id": "$ALERT_ID",
  "dedup_key": "$DEDUP_KEY",
  "name": "$ALERT_NAME",
  "description": "$ALERT_DESCRIPTION",
  "alert_action": "$ALERT_ACTION",
  "alert_url": "$ALERT_URL",
  "log_url": "$LOG_URL",
  "service": "$SERVICE",
  "threshold": "$ALERT_THRESHOLD",
  "duration": "$DURATION",
  "severity": "$EVENT_SEVERITY",
  "priority": "$ALERT_PRIORITY",
  "text": "$LOG_TEXT",
  "team": "$TEAM_NAME",
  "application": "$APPLICATION_NAME",
  "subsystem": "$SUBSYSTEM_NAME"
}

```

3. Next, click `Test & Save`.

<img />

<Check>If you see a test incident in All Quiet, that means successfully set up the webhook integration. Next, we need to add your [**Coralogix Alerts**](/integrations/inbound/coralogix#send-coralogix-alerts-to-all-quiet) to your integration to automatically forward them to All Quiet.</Check>

<img />

#### Send Coralogix Alerts to All Quiet

Back in your Coralogix webhook integration, you can add "Alert Notifications".

1. Make sure to activate the `Notify When Resolved` toggle to auto-[resolve](/essentials/incident#resolving) All Quiet incidents when the alert in Coralogix is resolved.
2. Select all alerts that you want to forward to All Quiet to create incidents using your webhook integration.
3. Click `Done` to finish the setup.

<img />

<Check> You're ready to go. If you set up your integration this way, Coralogix alerts will automatically create and update All Quiet incidents.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Coralogix.tf) the default mapping of the `allquiet_integration_mapping` resource for the Coralogix integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# All Quiet Cron Job Monitor
Source: https://docs.allquiet.app/integrations/inbound/cron-job-monitor

Use our Cron Job Monitor - your built-in dead man's switch - to watch your cron jobs' health and alert you the moment a job fails to run or is delayed.

<Info>Setup time: 2 Min</Info>

Set up our All Quiet Cron Job Monitor to ensure your scheduled jobs, scripts, and automations run on time. The monitor is set up within a few clicks. After setting it up, we'll create incidents to if a job fails to run or is delayed.

## 1. Create All Quiet Cron Job Monitor

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Cron Job Monitor as the integration's type

1. Enter a `Display Name` for your integration, e.g. "Cron Job Monitor".
   <Tip>Pick a name that makes it obvious which service the monitor belongs to.</Tip>

2. Select a `Team`.

3. Select `Cron Job Monitor` as the integration's type.

4. Click `Create Inbound Integration`.

<img />

## 2. Configure your Cron Job Monitor

Once you've set up the "Cron Job Monitor", it's time to configure it. This can be done on the the integration's page.

1. Here you find the unique Webhook URL that you need to ping.
2. Add a `Cron Expression` to define when you'd expect your cron job to run and ping the Webhook URL.
3. Add the cron job's timezone.
4. You may add a `Gace Period`. If the cron job is delayed but still finished and sending a ping to our Webhook URL within a `Grace Period`, we will not create an incident.
5. Define a severity for incidents being created if the cron job monitor fails.
6. `Save` your settings.
7. As you can see the monitor is not activated yet.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the cron job settings to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

<Check>Your monitor is now set up and ready to be activated.</Check>

### Start Cron Job Monitoring

To start monitoring, ping the Webhook URL you retrieved in the previous step.
On the bottom of the page, you will see

1. The last time a ping was received.
2. The next time a ping is expected based on your settings. If we don't receive a ping until then, we'll create an All Quiet incident and notify you.
3. After the second ping, we will start showing the current status of the Monitor
   * `On Time` if the last cron job was finished within the expected timeframe (plus optional grace period)
   * `Overdue` if we created an incident because we didn't receive the latest ping on time.

<img />

<Check>Your monitor is active.</Check>
<Note> After changing your monitor's settings, you’ll need to reactivate it by sending a new ping to the Webhook URL.</Note>


# CrowdStrike
Source: https://docs.allquiet.app/integrations/inbound/crowdstrike

Connect CrowdStrike Falcon with All Quiet

<Info>Setup time: 5 Min</Info>

Integrate Crowdstrike Falcon with All Quiet in a matter of minutes. With webhooks, you can automatically send alerts from CrowdStrike Falcon directly to All Quiet, streamlining your team's incident management process.

## 1. Create CrowdStrike Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select CrowdStrike as the integration's type

1. Enter a `Display Name` for your integration, e.g. "CrowdStrike".
2. Select a `Team`.
3. Select `CrowdStrike` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet Webhook URL

After creating the integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on CrowdStrike.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure the Integration with CrowdStrike

Once you've set up an integration of type "CrowdStrike" with All Quiet, it takes only three more steps in your CrowdStrike account to finish off your setup.

### Set up the Webhook to All Quiet

Sign in to your CrowdStrike Account.
We first need to create the Webhook

1. From the home screen, open the side navigation and select `CrowdStrike Store`
2. Select `All apps`

<img />

1. In the store, search for \`Webhook\`\`
2. Select the `CrowdStrike Webhook`

<img />

1. Click `Configure`
2. Select `Add configuration`

<img />

1. Select a name for you Webhook, like `All Quiet`
2. As `Webhook URL`, paste in the All Quiet Webhook URL you've obtained in step [Get the All Quiet Webhook URL](/integrations/inbound/crowdstrike#get-the-all-quiet-webhook-url).
3. **Remove** the `HMAC Secret Keys`
4. **Remove** the `Signature Header Name`
5. Save the Webhook.

<img />

<Check>You've successfully created the Webhook. Next, we need to set up a workflow to create All Quiet incidents from CrowdStrike, using the Webhook.</Check>

### Set up Workflow for Incident Creation

Now, we need to set up a workflow to **create** All Quiet incidents from CrowdStrike.

1. In the sidebar navigation, select \`Fusion SOAR\`\`
2. Open `Workflows`

<img />

In the workflows overview, select `Create workflow`

<img />

1. Select `Create workflow from scratch`
2. Click `Next`

<img />

Define the trigger. To select a trigger that creates new incidents,

1. open the `Endpoint security` section
2. and select `Alert` / `Detection`. This [selection differs from the worflow we will create later to update incidents that already got created](/integrations/inbound/crowdstrike#set-up-workflow-for-incident-updates)

<Tip>In the latest version of CrowdStrike Falcon Fusion, the “Alert” trigger has been renamed to “Detection.” If you encounter references to “Alert” in the information below, look for “Detection” instead in your current version of CrowdStrike.</Tip>

<img />

1. After selecting `Alert` / `Detection` click `Next`.

<img />

1. Now, we need to add an `Action` to the triggering alert / detection.
2. Select the `CrowdStrike` section.
3. Select `Call webhook`.

<img />

Now, we need to configure the `Call webhook` action.

1. As Webhook, select the `All Quiet` Webhook we configured in the [previous step](/integrations/inbound/crowdstrike#set-up-the-webhook-to-all-quiet).
2. For Data format, select `Default`.
3. As Data to include, select **all `Alert` objects / all `Detection` objects** from the dropdown and add them.
4. Click `Next`.

<img />

We're almost done with this step. Time to `Save and exit` the workflow.

<img />

To `save and exit`,

1. Give your worflow a name, like `All Quiet Create Incident`
2. Don't forget to activate it.
3. Confirm.

<img />

<Check>You're now able to create All Quiet incidents from CrowdStrike. In order to being able to update - e.g resolve - them from CrowdStrike, we need to add an extra, pretty similar workflow in the next step.</Check>

### Set up Workflow for Incident Updates

Add an extra Workflow.

1. This time, select `Audit event > Alert` / `Audit event > Detection` as trigger, as we want to listen to updates for existing incidents.

<img />

1. As we want to listen to all kinds for updates, select `All` as type and continue.

<img />

After setting up the trigger, add the similar action with the same settings as in the previous step when defining the [workflow to create incidents](/integrations/inbound/crowdstrike#set-up-workflow-for-incident-creation). This ensures incident updates are sent to All Quiet via the same webhook.

<img />

When saving the workflow

1. Make sure to add a suitable name, like `All Quiet - Update Incident`.
2. Activate the workflow.
3. And click `Save and exit` to confirm.

<img />

<Check> You're ready to go. If you set up your integration this way, CrowdStrike alerts / detections will automatically create and update All Quiet incidents.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/CrowdStrike.tf) the default mapping of the `allquiet_integration_mapping` resource for the CrowdStrike integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Dash0
Source: https://docs.allquiet.app/integrations/inbound/dash0

Connect Dash0 with All Quiet

<Info>Setup time: 5 Min</Info>

Integrate Dash0 with All Quiet in a matter of minutes. With webhooks, you can automatically send alerts from Dash0 directly to All Quiet, streamlining your team's incident management process.

## 1. Create Dash0 Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Dash0 as the integration's type

1. Enter a `Display Name` for your integration, e.g. "Dash0".
2. Select a `Team`.
3. Select `Dash0` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet Webhook URL

After creating the integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on Dash0.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure the Integration with Dash0

Once you've set up an integration of type "Dash0" with All Quiet, it takes only two more steps in your Dash0 account to finish off your setup.

### Set up the Notification Channel

Sign in to your Dash0 Account.
We first need to create the Notification Channel that allows us to connect Dash0 with All Quiet.

1. From the home screen, click on your organization.
2. Next, select `Open organization settings`.

<img />

In the organization settings,

1. Click `Notification Channels`
2. Click `+ New notification channel`
3. Select `All Quiet`

<img />

1. Give your notification channel a `Name`, e.g. `All Quiet`.
2. As `URL`, paste in the All Quiet Webhook URL you've obtained in step [Get the All Quiet Webhook URL](/integrations/inbound/dash0#get-the-all-quiet-webhook-url).
3. Select your personal settings for reminders. Reminders will trigger a new payload sent to All Quiet. We rather recommend using our [escalations](/essentials/escalations) for reminding alerts, as new payloads sent for an open incident don't trigger new alerts in our system to prevent alert fatigue.
4. Save your settings.
5. Optional: Send a test alert. If the notification channel is configured correctly, you will find a test incident in your connected All Quiet account.

<img />

<Check>You successfully set up the notification channel. Next, we need to add this channel to your Dash0 alerts to automatically forward them to All Quiet.</Check>

### Set up the Notification Rule

1. In the sidebar navigation, open the `Alerting` section
2. and select `Notifications`
3. Click `+ Create new notification rule`

<img />

1. Give a `Name` to your notification rule.
2. Optionally, you can filter for specific issues
3. Click `Add notification channel` and select the channel you set up in the [previous step](/integrations/inbound/dash0#set-up-the-notification-channel).
4. Save the notification rule.

<img />

<Check> You're ready to go. If you set up your integration this way, Dash0 alerts will automatically create and update All Quiet incidents.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Dash0.tf) the default mapping of the `allquiet_integration_mapping` resource for the Dash0 integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Datadog
Source: https://docs.allquiet.app/integrations/inbound/datadog

Connect Datadog monitoring to All Quiet

<Info>Setup time: 5 Min</Info>

Integrate Datadog's notifications with All Quiet's Webhooks for streamlined incident management.

## 1. Create an integration on All Quiet

### Create a Datadog integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Datadog as the integration's type

1. Enter a `Display Name` for your integration, e.g. "Datadog".
2. Select a `Team`.
3. Select `Datadog` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet webhook URL

Copy your integration's webhook URL. You'll need it later on the Datadog platform to connect Datadog alerts with All Quiet.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure DataDog

The following steps will be done on the Datadog platform. So, log in to Datadog with your account.

### Install Webhooks integration

1. In the navigation menu, click on `Integrations`
2. Install the `Webhooks` integration and configure it

<img />

### Create a new webhook

In the `Configuration` tab, click on `New Webhook`

<img />

### Configure DataDog webhook

1. Give your webhook a name, e.g. "All-Quiet-Webhook"
2. Paste in the All Quiet webhook URL you've obtained in step [Get The All Quiet Webhook URL](/integrations/inbound/datadog#get-the-all-quiet-webhook-url).
3. Configure the payload that Datadog should send to All Quiet. You can copy & paste the JSON snippet `datadog-payload.json` provided below.
4. Finally, save the integration.

```JSON datadog-payload.json theme={null}
{
    "body": "$EVENT_MSG",
    "last_updated": "$LAST_UPDATED",
    "event_type": "$EVENT_TYPE",
    "title": "$EVENT_TITLE",
    "date": "$DATE",
    "org": {
        "id": "$ORG_ID",
        "name": "$ORG_NAME"
    },
    "id": "$ID",
    "alert_id": "$ALERT_ID",
    "alert_status": "$ALERT_STATUS",
    "alert_title": "$ALERT_TITLE",
    "alert_type": "$ALERT_TYPE",
    "alert_metric": "$ALERT_METRIC",
    "alert_priority": "$ALERT_PRIORITY",
    "link":"$LINK",
    "snapshot":"$SNAPSHOT"
}
```

<img />

### Configure your monitor

1. Click on `Monitors`
2. Select one of your monitors and open its edit page. In this example, the monitor's name was "My Watchdog Monitor".
3. In the subsection "Configure notifications & automations", tag your newly created hook with "@webhook-Your-Webhook-Name". This will tell Datadog to use your webhook integration as a notification destination.

<img />

### Set your monitor's priority

1. Within step "Configure notifications & automations", scroll down to section "Metadata"
2. You'll find a select box to set the priority of your monitor.
3. `P1`,`P2` will map to severity `Critical`
4. `P3`,`P4` will map to severity `Warning`
5. `P5` will map to severity `Minor`
6. If you don't specify a priority, the incident's severity will be `Critical`

<img />

## 3. Test Notifications

These steps are important to successfully test your Datadog integration on the All Quiet side.

1. Click on `Test notifications` at the very bottom of the edit page.
2. Select `Alert` and click on `Run Test` to send out notifications to your newly created All Quiet integration.
3. Finally, don't forget to `Save` your integration!

<img />

<Check>
  Datadog's notifications with Webhooks are now successfully integrated into All
  Quiet, offering enhanced incident management capabilities and efficient policy
  management through an intuitive interface.
</Check>

### Datadog Alert as All Quiet Incident

You're done. 🥳 The next steps are merely there to verify if everything's setup correctly!

Go back to the All Quiet Web App and navigate to the “Incidents” overview. You will see the test incident created by Datadog. Open the details page to see the incident created. If you are missing anything, you can adjust the Alert on Datadog to send the info required and map it against an All Quiet incident in the payload mapping section of your Datadog inbound integration page on All Quiet.

<img />

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Datadog.tf) the default mapping of the `allquiet_integration_mapping` resource for the Datadog integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Dynatrace
Source: https://docs.allquiet.app/integrations/inbound/dynatrace

Connect Dynatrace to All Quiet

<Info>Setup time: 3 Min</Info>

Integrate Dynatrace into All Quiet by using our custom integration.

## 1. Add Dynatrace Integration to Your All Quiet Team

### Create a Dynatrace integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Dynatrace as the Integration's Type

1. Enter a `Display Name` for your integration, e.g. "Dynatrace".
2. Select a `Team`.
3. Select `Dynatrace` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet webhook URL

After creating the Dynatrace integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on Dynatrace.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Create a custom integration on Dynatrace

Sign in to your Dynatrace Account. Then, open `Settings`. The easiest way to get there is to use the search (cmd+k).

1. Search for "Settings"
2. Click on the search result.

<img />

1. In the sitenav, scroll down and open `Integration`.
2. Select `Problem notifications`.

<img />

`Add notification`

<img />

It's time to define the integration in Dynatrace.

1. Select `Custom Integration`
2. Select a `Display name`, e.g. "All Quiet"
3. Paste in the All Quiet webhook URL you've obtained in step [Get The All Quiet Webhook URL](/integrations/inbound/dynatrace#get-the-all-quiet-webhook-url).
4. Select `Call webhook if problem is closed` toggle.
5. Paste the following JSON snippet into the `Custom Payload` field:

```
{
"NamesOfImpactedEntities": "{NamesOfImpactedEntities}",
"PID": "{PID}",
"ProblemDetailsText": "{ProblemDetailsText}",
"ProblemID": "{ProblemID}",
"ProblemImpact": "{ProblemImpact}",
"ProblemSeverity": "{ProblemSeverity}",
"ProblemTitle": "{ProblemTitle}",
"ProblemURL": "{ProblemURL}",
"State": "{State}"
}
```

6. As Alerting Profile, select `Default`
7. Send test notification.

<img />

1. You'll receive a feedback if the test was successful.
2. `Save changes` to save your All Quiet integration in Dynatrace.

<img />

Returning to the All Quiet Web App, you will find the Dynatrace test notification on /app/incidents.

<img />

<Check>Dynatrace is now successfully integrated with All Quiet. To test if everything works as expected you can interact with any problem in Dynatrace, e.g. close an existing problem.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Dynatrace.tf) the default mapping of the `allquiet_integration_mapping` resource for the Dynactrace integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Elastic Observability
Source: https://docs.allquiet.app/integrations/inbound/elastic-observability

Connect Your Elastic Observability Projects with All Quiet

<Info>Setup time: 5 Min</Info>

Easily integrate Elastic with All Quiet. Automatically forward alerts from your Elastic observability projects to All Quiet, streamline your incident response.

## 1. Create Elastic Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Elastic Observability as the Integration's Type

1. Enter a `Display Name` for your integration, e.g. "Elastic Observability".
2. Select a `Team`.
3. Select `Elastic Observability` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet Webhook URL

After creating the integration on All Quiet, you can view the unique All Quiet Webhook URL of your Elastic integration.
You will require it in step 2 when configuring the custom integration on Elastic.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure a custom integration with Elastic Observability

Once you've set up an integration of type "Elastic Observability" with All Quiet, the next step is connect your Elastic Observability Project with All Quiet to forward Alerts to All Quiet.

Sign in to your Elastic account and open the project you want to connect with All Quiet.

<img />

### Create Connector

To send alerts to All Quiet, you first need to create a connection with All Quiet. Here's how:

1. Click on `Project settings`.
2. Then, select `Management`.
3. In the Management section, select `Connectors`.

<img />

Click `Create connector`.

<img />

As connector, select `Webhook`.

<img />

Set up a webhook that you can use to connect Elastic with All Quiet.

1. Select a name, e.g. `All Quiet`
2. As Method, select `Post`.
3. As `URL`, paste in the All Quiet Webhook URL you've obtained in step [Get the All Quiet Webhook URL](/integrations/inbound/elastic-observability#get-the-all-quiet-webhook-url).
4. As authentication method, select `None`.
5. Then, click `Save & Test`. In the next step, we can check if the connection was successful.

<img />

1. To test the connection, paste in the following body. You will also need it later when configuring rules for [real alerts](/integrations/inbound/elastic-observability#create-all-quiet-incidents-from-elastic-observability-alerts).

```Body elastic-observability-payload theme={null}
rule_url={{rule.url}}&rule_name={{rule.name}}&rule_type={{rule.type}}&rule_params={{rule.params}}&alert_id={{alert.id}}&alert_uuid={{alert.uuid}}&alert_actionGroup={{alert.actionGroup}}&alert_actionGroupName={{alert.actionGroupName}}&context_alertDetailsUrl={{context.alertDetailsUrl}}&context_alertState={{context.alertState}}&context_reason={{context.reason}}&context_value={{context.value}}&context_metric={{context.metric}}&context_tags={{context.tags}}&context_group={{context.group}}&context_threshold={{context.threshold}}
```

2. Click `Run`.
3. If the connection was establish, you will receive a sucess notification...

<img />

...and you will also find a test incident in All Quiet.

<Info>Please note since the're no real data to fill the body, you will only see the variable names in this case.</Info>

<img />

### Create All Quiet Incidents From Elastic Observability Alerts

Now, we want to use the connector we just created to send real alerts to All Quiet.

In the following, you can find an example how to set up an alerting rule for an incident in All Quiet. You can use your All Quiet connector for all your alerting rules in your Elastic Observability project and forward incidents to All Quiet.

1. First, Select `Alerts`.
2. Click `Manage Rules`.

<img />

You can either add the All Quiet connector as an Action to your existing Rules or create a new one. Here, we create a new rule.

<img />

For the example, we select "rule type" `Inventory`.

<img />

Now, we define a rule

1. Enter a `Name` and, optionally `Tags`. Note tha based on our pre-configured [default mapping](/essentials/inbound#mapping-payloads), this info will also be visible in All Quiet after an incident is created.
2. Select the conditions that trigger the rule. For "rule type" `Inventory`, you can add a `Warning` Threshold. By default, these alerts will trigger an All Quiet incident of severity "Warning", why `Alert` will trigger an incident with `Critical` severity.

Scroll down to add the actions.

<img />

Select Webhook.

<img />

1. Select the All Quiet Webhook connector you [set up earlier](/integrations/inbound/elastic-observability#create-connector).
2. We recommend setting Action frequency to "For each alert" and "On status changes". This means that the webhook will be triggered when the status is changed to the status selected in 3 and forward the new information to All Quiet.
3. With this selection, the webhook is only triggered when the status changes to `Alert`.**Note** that it will not be triggered if there's a chance to another status (that's why we added 5.)
4. Paste in this same `Body` to send a payload that works in All Quiet.

```Body elastic-observability-payload.json theme={null}
rule_url={{rule.url}}&rule_name={{rule.name}}&rule_type={{rule.type}}&rule_params={{rule.params}}&alert_id={{alert.id}}&alert_uuid={{alert.uuid}}&alert_actionGroup={{alert.actionGroup}}&alert_actionGroupName={{alert.actionGroupName}}&context_alertDetailsUrl={{context.alertDetailsUrl}}&context_alertState={{context.alertState}}&context_reason={{context.reason}}&context_value={{context.value}}&context_metric={{context.metric}}&context_tags={{context.tags}}&context_group={{context.group}}&context_threshold={{context.threshold}}
```

5. As we also want to be updated when the status changes to `Warning` or `Recovered`, we need to add 2 more actions in this case.

<img />

1. Set up the same action as before, but change the status that makes it run, here `Recovered`.
2. Paste in the same body.
3. Add a third action for `Warning` (only if you added a `Warning` condition earlier).

After configuring all Actions, safe the rule.

<img />

You can now find and edit it under `Rules`.

<img />

<Check>You have successfully connected All Quiet with your Elastic Observability project. Add the All Quiet connector as Action(s) to all your rules to forward all Alerts to All Quiet. </Check>

Below, you can see how the All Quiet incident looks based on the Inventory rule we created above.

<img />

When the status in your Elastic project changes to to `Recovered` adding the extra action for recovered ensures the incident in All Quiet is also `Resolved`.

<img />

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/ElasticObservability.tf) the default mapping of the `allquiet_integration_mapping` resource for the Elastic Observability integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Email
Source: https://docs.allquiet.app/integrations/inbound/email

Transform emails into incidents within All Quiet

<Info>Setup time: 4 Min</Info>

Integrate your email notifications with All Quiet using our this guide. Automatically generate a unique email address and send alerts from observability platforms straight to All Quiet. Learn how to fine-tune attribute mapping for accurate incident capture.

## Create Email Integrations

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Email".
2. Select a `Team`.
3. Select `Email` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

## Individual Email Recipient

1. Locate the unique email address under `Email Settings`. This is the address you'll use to send emails that automatically create incidents in the integration's team.
2. If you prefer to use a different email address, you can set up aliases in here.

<img />

### Send a Test Email

Begin by opening your preferred email client to compose a test message. This is simply a dry run to understand how emails are turned into structured incident reports in All Quiet. The exact content isn't important - it's just to illustrate the process. Once your email client is open, follow these steps:

1. As recepient, select the unique email address generated by your All Quiet email integration setup (or one the aliases you added).
2. Compose a sample email, entering a subject such as `New Incident` to represent the title of incident you'd like to report.
3. In the email `Body`, draft a mockup of incident details, for instance, adding a description and severity. You might as well add the environment it's in.

Next, send the email and wait a few seconds.

<img />

### Inspect Email Payload

Back in All Quiet, open the `Payload Mapping` tab of your Email integration.

1. You can see the email you just sent in latest email payloads received by the All Quiet platform.
2. Open the selected payload for more details. In will contain the actual data sent from your email client, including fields such as 'Message-ID', 'Subject', and 'To'.
3. Use the payload mapping to ensure the content of the email is mapped to an All Quiet incident that work for you. More details [below](/integrations/inbound/email#map-payload-attributes)
4. You can always see a preview of an All Quiet incident, based on the currently selected payload and your mapping.

<img />

## Map Payload Attributes

Review the attribute mapping configuration, which specifies how email content is mapped to incident attributes.

1. In this example, the `Body` attribute contains the whole body content. You may want to adjust this by adding [mapping steps](/essentials/inbound#mapping-payloads) to only extract a specific part.
2. Also, you can add additional attributes to enrich the incident with more info from the payload mappping.
3. Look at the incident preview in section to verify that the mapping has correctly transformed the email content into a structured incident, displaying fields such as `From` or `Body`. Note that due to the settings in this specific case, the `Body` is marked as `Hidden` and, therefore, will only be shown in incident details and not on the overview.

<img />

Find the All Quiet incident triggered by the email below.

<img />

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Email.tf) the default mapping of the `allquiet_integration_mapping` resource for the Email integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>

<Check> Attribute mappings have simplified transforming standard emails into structured incidents in All Quiet, bridging the gap between observability alerts and All Quiet's incident management for a smoother workflow.</Check>

#### Can emails automatically resolve an existing incident?

Yes — as long as your mapping can reliably set `Status` to `Resolved` for “OK” / recovery emails and can correlate those emails to the same incident.
In practice, you typically configure:

* `CorrelationId`: map a stable identifier (e.g. service, check name, host, environment) so follow-up emails update the same incident instead of creating a new one.
* `Status`: map `Open` vs `Resolved` based on some field in the email payload (for example the subject or a status field extracted from the body).

Important: make sure the JSONPath(s) you use for your mapping are **stable across all relevant emails** (alert + recovery). If the recovery email’s payload structure differs, adjust the mapping so both variants are handled correctly.

Learn more about [required/reserved attributes](/essentials/inbound#reserved-and-required-attributes). and [multiple payloads](/essentials/inbound#handling-multiple-payloads) in our Inbound Integrations docs.


# Google Cloud
Source: https://docs.allquiet.app/integrations/inbound/gcm

Connect Your Google Cloud Monitoring to All Quiet

<Info>Setup time: 4 Min</Info>

Connect Google Cloud Monitoring to All Quiet for enhanced alert management and efficient incident response.

## 1. Create Your Google Cloud Monitoring Integration on All Quiet

Login into your All Quiet account.

### Create Google Cloud Monitoring Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Google Cloud Monitoring".
2. Select a `Team`.
3. Select `Google Cloud Monitoring` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Copy Webhook URL

After successfully creating your Google Cloud Monitoring integration, make sure to copy the webhook URL. You'll need it later when setting up your notification channel in Google Cloud Monitoring.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Set up Your Google Cloud Monitor

Login into your Google Cloud Console.

### Create Notification Channel

1. Navigate to the "Monitoring" section of your Google Cloud Console.
2. Within the "Monitoring" section, choose the "Alerting" option, as highlighted. You can also search within your Google Cloud Console for "Alerting".
3. To modify notification settings, click on the `EDIT NOTIFICATION CHANNELS` button.

<img />

Click `ADD NEW` in the Webhooks section to create a new Webhook to All Quiet.

<img />

1. Enter the Webhook URL of step [Copy Webhook URL](/integrations/inbound/gcm#copy-webhook-url).
2. Enter a Display Name for your notification channel, e.g. "All Quiet".
3. Click "TEST CONNECTION" to send a test payload to the All Quiet webhook.
4. When the test notification was sent successfully, click "SAVE" to create the channel.

<img />

### Configure Alerting Policies

1. To utilize your new 'All Quiet' notification channel, either select an existing alerting policy or create a new one. Click on "Notifications and name", followed by "Notification Channels".
2. Select 'All Quiet' from your list of notification channels.
3. Ensure you check "Notify on incident closure" to enable automatic resolution of incidents in 'All Quiet'.

<img />

## 3. Test Your Google Cloud Monitoring Integration

You're almost done. 🥳 The next steps are merely there to verify if everything's setup correctly!

Navigate back to your Google Cloud Monitoring Integration in All Quiet that you've created in step [Create Google Cloud Monitoring Integration](/integrations/inbound/gcm#create-google-cloud-monitoring-integration).
Open the `Payload Mapping` tab.

1. Click `Reload` to load your latest payloads.
2. Select the latest payload. Be aware that the very first payload GCM might send you a test message. This payload might not map correctly to All Quiet's incidents. If you haven't received a payload from a real alarm yet, you can use the default example payload that is prefilled.
3. You can see how the mapping will transform this GCM payload to an All Quiet incident.

<img />

<Check>Google Cloud Monitoring is now successfully integrated with All Quiet, enhancing your incident management capabilities.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/GoogleCloudMonitoring.tf) the default mapping of the `allquiet_integration_mapping` resource for the Google Cloud Monitoring integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# GitHub
Source: https://docs.allquiet.app/integrations/inbound/github

Create All Quiet incidents from GitHub issues

To create incidents in All Quiet by creating an issue in GitHub, please set up our [GitHub Outbound Integration](/integrations/outbound/github) first. <br /> Within the settings of your outbound integration, you can enable the option to [create All Quiet incidents from GitHub](/integrations/outbound/github#create-all-quiet-incidents-from-github) and use GitHub as an inbound integration, too.


# GitLab
Source: https://docs.allquiet.app/integrations/inbound/gitlab

Create All Quiet incidents from GitLab work items

To create incidents in All Quiet by creating a work item in GitLab, please set up our [GitLab Outbound Integration](/integrations/outbound/gitlab) first. <br /> Within the settings of your outbound integration, you can enable the option to [create All Quiet incidents from GitLab](/integrations/outbound/gitlab#create-all-quiet-incidents-from-gitlab) and use GitLab as an inbound integration, too.


# Grafana
Source: https://docs.allquiet.app/integrations/inbound/grafana

Connect Grafana Alerts to All Quiet

<Info>Setup time: 5 Min</Info>

### Introduction

Effortlessly enhance your incident management capabilities by connecting Grafana Alerts to All Quiet. Streamline your response to critical events with this essential integration guide.

## 1. Create Your Grafana Integration on All Quiet

Login into your All Quiet account.

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Grafana for the integration's type

1. Enter a `Display Name` for your integration, e.g. "Grafana".
2. Select a `Team`.
3. Select `Grafana` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet webhook URL

Now that you've successfully created your Grafana Integration, make sure to copy the webhook URL for later.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Setup Your Grafana Alerting

### Add Contact Point

Login into your Grafana instance.

1. Under "Alerting", click on "Contact points".
2. Click on `Add contact point` to create a new webhook contact point.

<img />

### Save All Quiet as Contact Point

1. Choose a name for your contact point, e.g. "All Quiet Webhook".
2. Select "Webhook" as the Integration Type.
3. Paste the All Quiet Webhook URL which you've acquired in.
4. Click "Test" to check whether the contact point in Grafana and webhook in All Quiet are set up correctly. Everything should work out of the box.
5. Click `Save contact point`.

<img />

### Notification Policies

1. Navigate to "Notification policies" under "Alerting".
2. Click on `Edit` to edit your desired policy. In this example we're editing the default notification policy.

<img />

1. Select your All Quiet Webhook as the default contact point.
2. Click `Update policy` to save the changes.

<img />

## 3. Test Your Grafana Integration

You're almost done. 🥳 The next steps are merely there to verify if everything's setup correctly!

Navigate back to the Grana Integration that you've created in All Quiet

1. Click *`Reload`* to load the latest payloads that this webhook received.
2. Select to load one of the test incident's payload that was created in step into the payload field.
3. You can see how the mapping will transform this Grafana payload into an All Quiet incident.

<img />

<Check> Grafana Alerts are now successfully integrated with All Quiet, enhancing your incident management capabilities.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Grafana.tf) the default mapping of the `allquiet_integration_mapping` resource for the Grafana integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# All Quiet Heartbeat Monitor
Source: https://docs.allquiet.app/integrations/inbound/heartbeat-monitor

Use our Heartbeat Monitor - your built-in dead man's switch notifies you instantly if a heartbeat is missed, so you can react before issues escalate.

<Info>Setup time: 2 Min</Info>

Set up our All Quiet Heartbeat Monitor to to ensure your scheduled jobs, background tasks, and critical services are always running. The monitor is set up within a few clicks. After setting it up, we'll create incidents so you never miss a failed heartbeat.

## 1. Create All Quiet Heartbeat Monitor

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Heartbeat Monitor as the integration's type

1. Enter a `Display Name` for your integration, e.g. "Heartbeat".
   <Tip>Pick a name that makes it obvious which service the heartbeat monitor belongs to.</Tip>
2. Select a `Team`.
3. Select `Heartbeat Monitor` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

## 2. Configure your Heartbeat Monitor

Once you've set up the "Heartbeat Monitor", it's time to configure it. This can be done on the the integration's page.

1. Here you find the unique Webhook URL that you need to ping.
2. Add an `Interval`. This is the interval you'd expect your heartbeat to ping the Webhook URL
3. You may add a `Gace Period`. If the heartbeat is delayed and not sent in the `Interval` but still sent to our Webhook URL within the `Grace Period` following the `Interval`, we will not create an incident.
4. Define a severity for incidents being created if the Heartbeat Monitor fails.
5. `Save` your settings.
6. As you can see the monitor is not activated yet.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below your Heartbeat Monitor settings to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

<Check>Your monitor is now set up and ready to be activated.</Check>

### Start Hearbeat Monitoring

To start monitoring, ping the Webhook URL you retrieved in the previous step.
On the bottom of the page, you will see

1. The last time a heartbeat was received.
2. The next time a heartbeat is expected based on your settings. If we don't receive a heartbeat until then, we'll create an All Quiet incident and notify you.
3. After the second heartbeat, we will start showing the current status of the Monitor
   * `On Time` if the heartbeat was received within the expected timeframe (plus optional grace period)
   * `Overdue` if we created an incident because we didn't receive the latest heartbeat on time.

<img />

<Check>Your monitor is active.</Check>
<Note> After changing your monitor's settings, you’ll need to reactivate it by sending a new ping to the Webhook URL.</Note>


# Honeycomb
Source: https://docs.allquiet.app/integrations/inbound/honeycomb

Connect Honeycomb to All Quiet

<Info>Setup time: 3 Min</Info>

Integrate Honeycomb into All Quiet.

## 1. Create Honeycomb Integration on All Quiet

### Create a Honeycomb integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Honeycomb for the integration's type

1. Enter a `Display Name` for your integration, e.g. "Honeycomb".
2. Select a `Team`.
3. Select `Honeycomb` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet webhook URL and shared secret

After creating the Honeycomb integration on All Quiet, you can view and copy

1. the webhook URL
2. the shared secret

You will require these two in the next step when configuring the integration on Honeycomb.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Create an integration on Honeycomb

Open your Honeycomb, go to your `Account` and select `Team settings`.

<img />

1. Navigate to `Integrations`
2. Click `Add Integration`.

<img />

1. Choose `Webhook` as provider.
2. Enter a name, e.g. the name of your team at All Quiet
3. Paste in the All Quiet webhook URL you've obtained in step [Get The All Quiet Webhook URL and shared secret](/integrations/inbound/honeycomb#get-the-all-quiet-webhook-url-and-shared-secret).
4. Paste in the shared secret you've obtained in step [Get The All Quiet Webhook URL and shared secret](/integrations/inbound/honeycomb#get-the-all-quiet-webhook-url-and-shared-secret).

<img />

1. In Honeycomb, open `Triggers` page.
2. Either select a trigger you already created, or like us, set up a new trigger.

<img />

On the trigger page, select `Add Recipient`.

<img />

1. Select the integration you added ealier as your `Recipient`.
2. You can see the webhook URL and the encoded shared secret you added to the integration a few steps ago. Click `Add`.

<img />

Click `Create Trigger`, or, if you edited an existing trigger, safe changes.

<img />

Go back to `Account` > `Team settings` > `Integrations`.
Click `Test` for your All Quiet Integration.

<img />

`Send Test Alert`.

<img />

### Test Payload

Go back to your All Quiet Honeycomb integration that you've created in step [Create a Honeycomb Integration](/integrations/inbound/honeycomb#create-a-honeycomb-integration). Open the `Payload Mapping` section.

1. You will find the test incident in the `Latest Payload` section.
2. You can see how the mapping transforms the Honeycomb payload to an All Quiet incident.

<Check>Honeycomb is now successfully integrated with All Quiet. You can add the All Quiet Integration to as many triggers on Honeycomb as you like!</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Honeycomb.tf) the default mapping of the `allquiet_integration_mapping` resource for the Honeycomb integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Jira
Source: https://docs.allquiet.app/integrations/inbound/jira

Create All Quiet Incidents from Jira Issues

To create incidents in All Quiet by creating an issue in Jira, please set up our [Jira Outbound Integration](/integrations/outbound/jira), first. <br /> Within the settings of your Outbound Integration, you can enable the option to [create All Quiet Incidents from Jira](/integrations/outbound/jira#create-all-quiet-incidents-from-jira) and use Jira as an Inbound Integration, too.


# Linear
Source: https://docs.allquiet.app/integrations/inbound/linear

Create All Quiet Incidents from Linear Issues

To create incidents in All Quiet by creating an issue in Linear, please set up our [Linear Outbound Integration](/integrations/outbound/linear), first. <br /> Within the settings of your Outbound Integration, you can enable the option to [create All Quiet Incidents from Linear](/integrations/outbound/linear#create-all-quiet-incidents-from-linear) and use Linear as an Inbound Integration, too.


# Mattermost
Source: https://docs.allquiet.app/integrations/inbound/mattermost

Create Incidents from Your Mattermost Server

<Tip>To create incidents in All Quiet using Mattermost, please set up our [Outbound Integration for Mattermost](/integrations/outbound/mattermost), first. <br /> Then, you can define a custom command to [create new incidents from your connected Mattermost channels](/integrations/outbound/mattermost#create-incidents-from-mattermost).</Tip>


# Microsoft Teams
Source: https://docs.allquiet.app/integrations/inbound/microsoft-teams

Create Incidents from Your MS Teams Channels

<Tip>To create incidents in All Quiet using MS Teams, please set up our [MS Teams Outbound Integration](/integrations/outbound/microsoft-teams), first. <br /> Then, you can use the command `@All Quiet incident` to [create new incidents via your connected MS Teams Channels](/integrations/outbound/microsoft-teams#create-new-all-quiet-incidents-directly-from-ms-teams).</Tip>


# Nagios
Source: https://docs.allquiet.app/integrations/inbound/nagios

Connect Nagios Monitoring with All Quiet

<Info>Setup time: 10 Min</Info>

Integrate Nagios Monitoring with All Quiet in a matter of minutes. With webhooks, you can automatically send alerts from Nagios directly to All Quiet, streamlining your team's incident management process.

## 1. Create Nagios Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Nagios as the integration's type

1. Enter a `Display Name` for your integration, e.g. "Nagios".
2. Select a `Team`.
3. Select `Nagios` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet Webhook URL

After creating the integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on Nagios.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure the Integration with Nagios

Once you've set up an integration of type "Nagios" with All Quiet, it takes only four steps in your Nagios configuration to finish off your setup.

### Add All Quiet Notification Scripts for Nagios

Nagios differentiates between `Hosts` and `Services`. Depending on which of these you want to monitor with All Quiet, you need to add the respective shell script from below to a folder where Nagios can execute it, for instance `/usr/local/bin/allquiet/`.

```sh notify-allquiet-host.sh theme={null}
#!/usr/bin/env bash
set -euo pipefail

allquiet_webhook_url="$1"
nagios_url="$2"
notification_type="$3"
state="$4"
host="$5"
alias="$6"
output="$7"
problem_id="$8"
last_problem_id="$9"

correlation_problem_id="$problem_id"
if [ "$correlation_problem_id" = "0" ]; then
  correlation_problem_id="$last_problem_id"
fi

correlation_id="${host}:${correlation_problem_id}"

curl -sS -m 10 --fail -X POST \
  "${allquiet_webhook_url}" \
  -d "title=[${notification_type}] Host ${host}" \
  -d "src=host" \
  -d "type=${notification_type}" \
  -d "status=${state}" \
  -d "host=${host}" \
  -d "alias=${alias}" \
  -d "output=${output}" \
  -d "id=${correlation_problem_id}" \
  -d "link=${nagios_url}/cgi-bin/extinfo.cgi?type=1%26host=${host}" \
  -d "correlation_id=${correlation_id}" 
```

```sh notify-allquiet-service.sh theme={null}
#!/usr/bin/env bash
set -euo pipefail

allquiet_webhook_url="$1"
nagios_url="$2"
notification_type="$3"
state="$4"
service="$5"
host="$6"
output="$7"
problem_id="$8"
last_problem_id="$9"

correlation_problem_id="$problem_id"
if [ "$correlation_problem_id" = "0" ]; then
  correlation_problem_id="$last_problem_id"
fi

correlation_id="${host}:${service}:${correlation_problem_id}"

curl -sS -m 10 --fail -X POST \
  "${allquiet_webhook_url}" \
  -d "title=[${notification_type}] ${service} (${host})" \
  -d "src=service" \
  -d "status=${state}" \
  -d "type=${notification_type}" \
  -d "service=${service}" \
  -d "host=${host}" \
  -d "output=${output}" \
  -d "id=${correlation_problem_id}" \
  -d "link=${nagios_url}/cgi-bin/extinfo.cgi?type=2%26host=${host}%26service=${service}" \
  -d "correlation_id=${correlation_id}"
```

To finish this step, you need to ensure that the scripts are executable. Therefore, please run the following commands in the folders the scripts are saved in.

```txt Commands for Service and Host files; here named notify-allquiet-service.sh and notify-allquiet-hosts.sh  theme={null}
chmod +x {path}/notify-allquiet-service.sh
chmod +x {path}/notify-allquiet-host.sh
```

### Add Commands

Next, to send alerts to All Quiet, we need to define the commands.
Here, Nagios also differentiates between `Host` and `Service` commands.

Below, you find templates for both types of commands that you can paste into your `commands.cfg`, depending on which type(s) your are using.

<Tip>Make sure to **adjust lines 3-5** depending on your path, file name, Webhook URL from [previous step](/integrations/inbound/nagios#get-the-all-quiet-webhook-url) and your Nagios domain.</Tip>

```cfg Service Command highlight={3-5} lines theme={null}
define command {
    command_name    notify-allquiet-service    
    command_line    /usr/local/bin/allquiet/notify-allquiet-service.sh \
                "https://YOUR_WEBHOOK__URL_FROM_STEP_1" \
                "https://YOUR_NAGIOS_DOMAIN" \
                "$NOTIFICATIONTYPE$" \
                "$SERVICESTATE$" \
                "$SERVICEDESC$" \
                "$HOSTNAME$" \
                "$SERVICEOUTPUT$" \
                "$SERVICEPROBLEMID$" \
                "$LASTSERVICEPROBLEMID$"
}
```

```cfg Host Command highlight={3-5} lines theme={null}
define command {
    command_name    notify-allquiet-host
    command_line    /usr/local/bin/allquiet/notify-allquiet-host.sh \
                "https://YOUR_WEBHOOK__URL_FROM_STEP_1" \
                "https://YOUR_NAGIOS_DOMAIN" \
                "$NOTIFICATIONTYPE$" \
                "$HOSTSTATE$" \
                "$HOSTNAME$" \
                "$HOSTALIAS$" \
                "$HOSTOUTPUT$" \
                "$HOSTPROBLEMID$" \
                "$LASTHOSTPROBLEMID$"
}
```

Make sure to save your `commands.cfg`.

### Add All Quiet Contact

Next, we need to add All Quiet as a contact to your `contacts.cfg` in Nagios.

<Tip> Make sure to include your command(s) name(s) from above.</Tip>

```cfg Example Contact highlight={8-9} theme={null}
define contact {
    contact_name                    allquiet
    alias                           All Quiet
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,r
    service_notification_commands   notify-allquiet-service
    host_notification_commands      notify-allquiet-host
    email                           none@example.com
}
```

Make sure to save your `contacts.cfg`.

### Add Contact to Your Services and Hosts

Last but not least, you need to add the contact (here: `allquiet`) to your defined `Service(s)` and / or `Host(s)`, allowing you to trigger the Nagios Commands if your `Services` or `Hosts` report an issue.

```cfg Add Contact to Your Services and Hosts theme={null}
...
contact     allquiet
...
```

Afterwards Make sure to save your Nagios config and restart to apply changes.

<Check> You're ready to go. If you set up your integration this way, Nagios alerts will automatically create and update All Quiet incidents.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Nagios.tf) the default mapping of the `allquiet_integration_mapping` resource for the Nagios integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Netdata
Source: https://docs.allquiet.app/integrations/inbound/netdata

Connect Netdata Monitoring with All Quiet

<Info>Setup time: 2 Min</Info>

Easily integrate Netdata with All Quiet. With webhooks, you can automatically send alerts from your Netdata monitoring directly to All Quiet, streamlining your incident management.

## 1. Create Netdata Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Netdata as the integration's type

1. Enter a `Display Name` for your integration, e.g. "Netdata".
2. Select a `Team`.
3. Select `Netdata` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Webhook URL and Netdata Challenge Secret

After creating the integration on All Quiet, you can view

1. the `Webhook URL`.
2. the `Netdata Challenge Secret`.

You will require both, the URL and the Challenge Secret in step 2 when configuring the custom integration on Netdata.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure a custom integration with Netdata

Once you've set up an integration of type "Netdata" with All Quiet, the next crucial steps involve configuring your Netdata account. This is essential for ensuring that your monitoring setup can effectively send incidents to the All Quiet webhook. In this part of the guide, we will walk you through the process of linking Netdata with All Quiet via webhook.

First, you need to sign in to your Netdata Account and open `Settings`

<img />

1. Select `Alerts & Notifications`
2. Click `+ Add configuration`

<img />

Add `Webhook`

<img />

Now, it's time to set up the integration.

1. Select a `Configuration name`, e.g. "All Quiet".
2. Select the `Rooms` from which you would like to forward alerts to All Quiet.
3. Select the type of `Notifications` you would like to forward.
4. As `Webhook URL`, paste in the All Quiet Webhook URL you've obtained in step [Webhook URL and Netdata Challenge Secret](/integrations/inbound/netdata#webhook-url-and-netdata-challenge-secret).
5. As `Authentification details`, select "No Authentification".
6. As `Challenge secret`, paste in the Netdata Challenge Secret you've obtained in step [Webhook URL and Netdata Challenge Secret](/integrations/inbound/netdata#webhook-url-and-netdata-challenge-secret).
7. Click `OK` to save your settings. You can also test them, first (see 2nd Screenshot below).

<img />

If test is successful, you will receive a test payload from Netdata that can be found in the "Payload Mapping" tab of your All Quiet Netdata Integration.

1. The payload is there.
2. We **cannot map the test notification** as it missing some required attributes that we need to create incidents. Howewer, our **predefined mapping** engine will be able to **create incidents from real Netdata alerts**. Use our mapping engine to add further data to All Quiet incidents.

<img />

<Check>All Quiet will now create incidents based on your Netdata monitoring.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Netdata.tf) the default mapping of the `allquiet_integration_mapping` resource for the Netdata integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# New Relic
Source: https://docs.allquiet.app/integrations/inbound/newrelic

Connect New Relic Alerts into All Quiet

<Info>Setup time: 6 Min</Info>

Integrate New Relic with All Quiet for streamlined incident management and enhanced alert handling.

The process of integrating New Relic alerts involves only two steps:

1. Create a New Relic integration on the All Quiet platform to obtain a webhook URL.
2. Use this URL in New Relic to create a workflow with a webhook destination.

## 1. Create a New Relic integration on All Quiet

### 1.1 Create an Integration on All Quiet

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### 1.2 Select New Relic for the integration's type

1. Enter a `Display Name` for your integration, e.g. "New Relic".
2. Select a `Team`.
3. Select `New Relic` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### 1.3 Get the All Quiet webhook URL

Copy your webhook URL. You'll need it later on the New Relic platform.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Create a New Relic workflow with a webhook destination

The following steps will be done on the New Relic platform. So, log in to New Relic with your account.

### 2.1 Create an Alert Condition

1. Go to *Alerts & UI -> Alert Conditions (policies)*
2. Create an alert condition that you'd like to monitor. In the example provided, a condition has been added to monitor if the CPU load is above 50%.
3. Navigate to the *Notification settings* tab

<img />

### 2.2 Create a workflow

In the Notification settings, click `Create workflow`

<img />

### 2.3 Add Webhook channel

Click on `Webhook` to add a webhook notification channel

<img />

### 2.4 Add a destination to Webhook channel

1. Enter a channel name, e.g. *"All Quiet Channel"*
2. Click on "Add a destination" to configure the destination (Webhook)

<img />

### 2.5 Configure Webhook channel

1. Enter a name for the Webhook, e.g. *"All Quiet Webhook"*
2. Paste the All Quiet webhook URL from [step 1.3.](/integrations/inbound/newrelic#1-3-get-the-all-quiet-webhook-url) into *Endpoint URL*
3. Click *"Save destination"*

<img />

### 2.6 Finish editing notification message

1. Now that you've configured a new destination, select the corresponding item for the *"Destination"* field.
2. Click *`Send test notification`*. It's helpful to send a test notification to All Quiet so you can easily map the message payload on the All Quiet platform.
3. Click *`Save message`.*

<img />

### 2.7. Active your workflow

Click `Activate Workflow`. Don't forget this step, otherwise, your workflow won't work!

<img />

## 3. Test the New Relic notification message payload

You're almost done. 🥳 You can now test how New Relic's palyoad maps to your All Quiet incident:

### 3.1 Load New Relic Payload

Go back to your All Quiet New Relic integration that you've created in [step 1.2.](/integrations/inbound/newrelic#1-2-select-new-relic-for-the-integration’s-type)

1. You will find the test notification payload New Relic sent to All Quiet.
2. With the our `Mapping` engine, you can transform New Relic alerts in any type of All Quiet incident that works for you.
3. Take a look at the incident preview at the bottom. It should be correctly mapped from New Relic's test notification.

<img />

<Check> Webhook integration with New Relic is now successfully configured on All Quiet, enhancing incident response efficiency.</Check>

### 3.2 Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/NewRelic.tf) the default mapping of the `allquiet_integration_mapping` resource for the New Relic integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Observium
Source: https://docs.allquiet.app/integrations/inbound/observium

Connect Observium Monitoring with All Quiet

<Info>Setup time: 10 Min</Info>

Integrate Observium with All Quiet in a matter of minutes. With a simple alert transport script, you can forward Observium alerts to your All Quiet inbound integration webhook URL, keeping incident handling consistent across your observability stack.

## 1. Create Observium Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Observium as the integration's type

1. Enter a `Display Name` for your integration, e.g. "Observium".
2. Select a `Team`.
3. Select `Observium` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Copy Webhook URL

After creating the integration on All Quiet, copy the webhook URL. You will require this URL in step 2 when configuring Observium.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure the Integration with Observium

Once you've set up an integration of type "Observium" with All Quiet, you can configure an alert transport script on your Observium host to forward alerts to All Quiet.

### Alert statuses (important)

Observium provides an alert status that indicates whether this is an alert, a recovery, or a suppressed/delayed notification.

* **`alert_status = 0`**: alert → creates / updates an incident
* **`alert_status = 1`**: recovery → resolves the incident
* **`alert_status = 2`**: delayed → dropped (does not create/update incidents in All Quiet default mapping)
* **`alert_status = 3`**: suppressed → dropped (does not create/update incidents in All Quiet default mapping)

<Tip>
  Post-processing also supports the alias `alertStatus` (camelCase) for `alert_status`. In this guide we use `alert_status`.
</Tip>

### Add an All Quiet alert script

Create a script on the Observium server, for example at `/usr/local/bin/observium-allquiet.sh`.

This script is intentionally shaped to match the default Observium mapping shipped with All Quiet (correlation = `alert_id` + `entity_id`, status and severity mapping, title composed from host + message, plus URL, conditions, metrics, entity type).

```sh observium-allquiet.sh theme={null}
#!/usr/bin/env bash
set -euo pipefail

# Paste the webhook URL from step 1 (use the correct region, e.g. .app or .eu).
WEBHOOK="PASTE_YOUR_WEBHOOK_URL_FROM_STEP_1"

# Observium's External-program transport exports alert fields as `OBSERVIUM_*`
# environment variables and executes the configured script without arguments.
# For manual testing, you can optionally pass positional arguments.
alert_id="${1:-${OBSERVIUM_ALERT_ID:-}}"
entity_id="${2:-${OBSERVIUM_ENTITY_ID:-}}"
alert_status="${3:-${OBSERVIUM_ALERT_STATUS:-}}"          # 0=alert, 1=recovery, 2=delayed (dropped), 3=suppressed (dropped)
alert_severity_raw="${4:-${OBSERVIUM_ALERT_SEVERITY:-}}"  # Critical|Warning|Informational
device_hostname="${5:-${OBSERVIUM_DEVICE_HOSTNAME:-}}"
alert_message="${6:-${OBSERVIUM_ALERT_MESSAGE:-}}"
alert_url="${7:-${OBSERVIUM_ALERT_URL:-}}"
conditions="${8:-${OBSERVIUM_CONDITIONS:-}}"
metrics="${9:-${OBSERVIUM_METRICS:-}}"
entity_type="${10:-${OBSERVIUM_ENTITY_TYPE:-}}"

# All Quiet's default mapping expects lowercase severity values.
alert_severity=$(printf '%s' "$alert_severity_raw" | tr '[:upper:]' '[:lower:]')

curl -sS -m 10 --fail -X POST "${WEBHOOK}" \
  -H 'Content-Type: application/json' \
  -d "$(jq -n \
    --arg alert_id         "$alert_id" \
    --arg entity_id        "$entity_id" \
    --arg alert_status     "$alert_status" \
    --arg alert_severity   "$alert_severity" \
    --arg device_hostname  "$device_hostname" \
    --arg alert_message    "$alert_message" \
    --arg alert_url        "$alert_url" \
    --arg conditions       "$conditions" \
    --arg metrics          "$metrics" \
    --arg entity_type      "$entity_type" \
    '{alert_id:$alert_id, entity_id:$entity_id, alert_status:$alert_status,
      alert_severity:$alert_severity, device_hostname:$device_hostname,
      alert_message:$alert_message, alert_url:$alert_url,
      conditions:$conditions, metrics:$metrics, entity_type:$entity_type}')"
```

Make it executable:

```txt theme={null}
chmod +x /usr/local/bin/observium-allquiet.sh
```

### Wire the script into Observium alerting

Configure Observium to execute the script when alerts fire and recover.

<Tip>
  Observium exports alert fields as environment variables (prefixed with `OBSERVIUM_...`) and then executes the configured command without positional CLI arguments.
  The important part is: point Observium to `/usr/local/bin/observium-allquiet.sh`.
</Tip>

Example invocation context (conceptually; Observium sets env vars and runs the script without args):

```txt theme={null}
OBSERVIUM_ALERT_ID=040109
OBSERVIUM_ENTITY_ID=780431
OBSERVIUM_ALERT_STATUS=0
OBSERVIUM_ALERT_SEVERITY=Critical
OBSERVIUM_DEVICE_HOSTNAME=101.131.544.3
OBSERVIUM_ALERT_MESSAGE=status changed -> [DOWN]
OBSERVIUM_ALERT_URL=https://...
OBSERVIUM_CONDITIONS=...
OBSERVIUM_METRICS=...
OBSERVIUM_ENTITY_TYPE=port
...

# Observium then executes the script without arguments:
/usr/local/bin/observium-allquiet.sh
```

For recoveries, Observium should export `OBSERVIUM_ALERT_STATUS=1` (the script forwards it as `alert_status`).

Manual test (optional):

```txt theme={null}
/usr/local/bin/observium-allquiet.sh 040109 780431 0 critical "host.example" "status changed -> [DOWN]" "https://example/url" "" "" port
```

## 3. Test Your Integration

Navigate back to All Quiet and open the `Payload Mapping` tab of the integration you just created.

1. Trigger a test alert in Observium.
2. Verify the payload shows up in `Latest payloads`.
3. Check that the pre-built mapping creates an incident with the expected `Title`, `Status`, and `Severity`.

<Check> You're ready to go. If you set up your integration this way, Observium alerts will automatically create and update All Quiet incidents.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? Download the default mapping template and tailor it to your needs from `https://allquiet.app/api/integrations/terraform/default/Observium.tf`.</Tip>


# All Quiet Ping Monitor
Source: https://docs.allquiet.app/integrations/inbound/ping-monitor

Use our Ping Monitor to check your hosts and IP addresses

<Info>Setup time: 2 Min</Info>

Set up our All Quiet Ping Monitor to ping your hosts or IP addresses anytime. The monitor is set up within a few clicks. After setting it up, we'll create incidents to inform you if anything is wrong.

## 1. Create All Quiet Ping Monitor

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Ping Monitor as the integration's type

1. Enter a `Display Name` for your integration, e.g. "IP Monitor".
   <Tip>Pick a name that makes it obvious which service the Ping monitor belongs to.</Tip>
2. Select a `Team`.
3. Select `Ping Monitor` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

## 2. Configure your Ping Monitor

Once you've set up the "Ping Monitor", it's time to configure it. This can be done on the the integration's page.

1. Select the `Host` you want to monitor, e.g an IP address. If you want to monitor different hosts, simply set up several monitors.
2. Select the `Timeout`, the duration after which the monitor should time out and considered to be failed.
3. Select how often the Monitor should `retry` the request before creating an incident if something is wrong.
4. `Interval`: Select how often the monitor should be triggered.

<Note>
  Retries happen inside a single check, not across intervals. With Max Retries = 5, All Quiet does 1 initial ping + up to 5 retries (6 attempts total). Each attempt uses the Timeout. Between failed attempts there is only a short backoff (tens to hundreds of ms), not another full timeout wait.
</Note>

5. Select the **severity** of incidents triggered for `Degraded` monitor results.
6. Select the **severity** of incidents triggered for `Down` monitor results.
7. To finish your setup, click `Save Monitor Settings`.

<Info>You can always pause your monitor by activating the toggle at the top of the settings and saving. </Info>

<img />

<Check>Your Ping Monitor is now set up, configured and running.</Check>

### Test your Monitor

We recommend testing your monitor after setting it up to see if it works as expected.
After saving the monitor,

1. Click "Execute" in the `Last Response` section.
2. You'll find the result below. Here, the monitor fails...

<img />

### Incident creation from Monitor

A failed monitor will create an All Quiet incident, visible on your incidents overview.

<img />

### How Ping Monitoring Status Handling Works

When Ping monitoring checks a target, the system compares the new status with the most recent one. If the status has changed (for example, from Up to Down or from Down to Up), the system processes the result fully. This includes updating records, sending notifications, and managing incidents.

If the status remains the same (for example, Up to Up or Down to Down), the system stops early without further processing. This prevents duplicate alerts and avoids unnecessary incident creation. You can also see this in the `Response Logs` at the bottom of the `Ping Monitor Settings` page. The reponse logs will only show one entry per status change, but will update the timestamp based on the last ping for the given status.

This behavior differs from other inbound integrations, which create a new incident whenever an alert is received if there is no open incident yet. Ping monitoring is designed to reduce noise by only acting when a real status change occurs.

<img />

<Tip> If you close an incident manually and the status has not changed, the system will not create a new incident for the same issue. This helps you stay focused on real changes, reduces unnecessary noise, and keeps incident management cleaner.</Tip>


# Pingdom
Source: https://docs.allquiet.app/integrations/inbound/pingdom

Connect Pingdom Website Monitoring with All Quiet

<Info>Setup time: 2 Min</Info>

Seamlessly integrate Pingdom with All Quiet. With webhooks, you can automatically send alerts from your Pingdom monitoring directly to All Quiet, streamlining your incident management.

## 1. Create Pingdom Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Pingdom as the integration's type

1. Enter a `Display Name` for your integration, e.g. "Pingdom".
2. Select a `Team`.
3. Select `Pingdom` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Copy Webhook URL

After creating the integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on Pingdom.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure a custom integration with Pingdom

Once you've set up an integration of type "Pingdom" with All Quiet, the next crucial steps involve configuring your Pingdom account. This is essential for ensuring that your monitoring setup can effectively send incidents to the All Quiet webhook. In this part of the guide, we will walk you through the process of linking Pingdom with All Quiet via webhook.

First, you need to sign in to your Pingdom Account.

1. Open `Settings`
2. Select `Integrations`

<img />

Click `Add integration`.

<img />

Now, it's time to set up the integration.

1. As type, select `Webhook`.
2. Select a name for the integration, e.g. `All Quiet`.
3. As URL, paste in the All Quiet webhook URL you've obtained in step [Get The All Quiet Webhook URL](/integrations/inbound/pingdom#copy-webhook-url).
4. Make sure the integration is `Active`.
5. `Save integration`

<img />

Now, add the integration to all your Pingdom Checks for which you want to send alerts to All Quiet if something is wrong. For each Check, click `edit`.

1. Scroll down to `Connect Integrations` and activate the checkmark for the All Quiet integration you just created.
2. We recommend testing the integration. After clicking on `Test`. You should receive a test incident in All Quiet. Make sure to save the changes by clicking `Modify check`.

<img />

<Check>All Quiet will now create incidents based on your Pingdom monitoring.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Pingdom.tf) the default mapping of the `allquiet_integration_mapping` resource for the Pingdom integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Prometheus
Source: https://docs.allquiet.app/integrations/inbound/prometheus

Connect Prometheus Alertmanager with All Quiet

<Info>Setup time: 5 Min</Info>

Integrate All Quiet with your Prometheus seamlessly. Automatically send alerts directly to All Quiet, streamlining incident management.

## 1. Create Prometheus Integration on All Quiet

Login into your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Prometheus for the integration's type

1. Enter a `Display Name` for your integration, e.g. "Prometheus".
2. Select a `Team`.
3. Select `Prometheus Alertmanager` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Copy Webhook URL

After successfully creating your Prometheus Alertmanager integration, make sure to copy the webhook URL.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure Prometheus Alertmanager

Once you've set up an integration of type "Prometheus Alertmanager" with All Quiet, the next crucial steps involve configuring your Prometheus and Alertmanager instances. This is essential for ensuring that your monitoring setup can effectively send incidents to the All Quiet webhook. In this part of the guide, we will walk you through simple yet effective configuration examples for both Prometheus and Alertmanager.

### Setting Up Prometheus

First, let's start with the Prometheus configuration. Your prometheus.yml should include the necessary scrape configs to monitor your targets. Here’s an example of a basic configuration:
In your prometheus.yml, the configuration should primarily include scrape\_configs and alerting details. Below is an example configuration:

```YML theme={null}
scrape_configs:
  - job_name: 'allquiet.app'
    scrape_interval: 5s
    scheme: https
    metrics_path: /status
    static_configs:
      - targets: ['allquiet.app']

rule_files:
  - "*.rules"

alerting:
  alertmanagers:
    - scheme: http
      static_configs:
        - targets: [ 'your-prometheus-alertmanager.yourdomain.com:9093' ]
```

In this configuration,`scrape_configs` defines the job for scraping metrics from `allquiet.app`, with a frequent interval of every 5 seconds. We're observing our own platform in this example :). The `https` scheme and`/status` metrics path dictate how Prometheus accesses the data.

The `rule_files` section tells Prometheus to load any alerting rules from files ending with `.rules`.

The alerting section is crucial for the integration. It specifies that Prometheus should send alerts to an Alertmanager instance located at `your-prometheus-alertmanager.yourdomain.com:9093`.

With these settings, Prometheus is configured to monitor `allquiet.app` closely and forward alerts to Alertmanager, which then communicates with the All Quiet platform, ensuring efficient incident management.

### Setting Up Alert Rules

After configuring the `prometheus.yml` file, the next step in integrating Prometheus with All Quiet is to set up alert rules. Alert rules in Prometheus define the conditions under which an alert should be fired. Below is a sample alert rule file that demonstrates how to create a rule for monitoring response times.

Here's the alert rule configuration:

```YML theme={null}
groups:
- name: allquiet.app
  rules:
  - alert: Response Time slow
    expr: scrape_duration_seconds{job="allquiet.app"} > 0.1
    for: 5s
    labels:
      severity: critical
    annotations:
      description: "Response time is bad"
```

This rule is set up under a group named `allquiet.app`. The rule `Response Time slow`triggers an alert if the `scrape_duration_seconds` for the `allquiet.app` job exceeds 0.1 seconds, sustained over a period of 5 seconds. This means if the response time of the monitored service goes beyond 100 milliseconds and stays that way for at least 5 seconds, an alert is triggered.

The `labels` section classifies the alert's severity as `critical`, which can be useful for advanced routing and handling the alert. The annotations section provides a descriptive message for the alert, e.g. indicating that the response time of the service is poor. :)

By implementing this alert rule, you can effectively monitor critical performance metrics like response times and ensure that such issues are promptly flagged and communicated to the All Quiet platform for efficient incident management.

### Setting Up Alertmanager

The final step in integrating Prometheus Alertmanager with All Quiet is to configure the Alertmanager itself. This configuration ensures that Alertmanager appropriately routes, groups, and sends alerts to the All Quiet platform. Here's how to set up the Alertmanager using the provided YAML configuration:

In this configuration:

```YAML theme={null}
route:
  route:
  group_by: ['...']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'allquiet'

receivers:
  - name: 'allquiet'
    webhook_configs:
      - url: 'https://allquiet.app/api/webhook/71873b0f-fce1-28a1-b3g6-2362ff95123e7'
```

* The `route` section defines how alerts are processed and sent to receivers. `group_wait`sets the time to wait before sending a notification about new alerts that are added to a group of alerts. `group_interval` sets the interval between sending notifications about the same group of alerts, while `repeat_interval` controls how long to wait before sending repeat notifications. **We recommend to avoid grouping alerts as we will only create one and not several incidents based on one payload / Prometheus alert. You can achieve this by using the `group_by` condition as in the example above**.
* The `receiver` parameter within the `route` is set to `'allquiet'`. This tells Alertmanager to use the `allquiet` receiver for notifications.
* In the `receivers` section, a receiver named `allquiet` is defined. This receiver uses`webhook_configs` to send alerts to the specified URL, which is the webhook provided by All Quiet in [Copy Webhook URL](https://allquiet.app/blog/connect-prometheus-alertmanager#copy-webhook-url).

By applying this configuration, you ensure that Alertmanager routes alerts to All Quiet efficiently. The alerts are grouped and sent based on the defined intervals, and the webhook URL ensures that these alerts are received by All Quiet for effective incident management. This setup completes the integration process, enabling your monitoring system to communicate seamlessly with All Quiet.

## 3. Test Your Integration

You're almost done. 🥳 The next steps are merely there to verify if everything's setup correctly!

Navigate back to All Quiet and open the `Payload Mapping` tab of the integration that you've just created.

1. Find the test payload in the`latest payloads`.
2. Our pre-configured `payload mapping` will transform Prometheus alerts into All Quiet incidents. You can adjust the mapping to your liking anytime.
3. Observe how the mapping transforms the selected Prometheus Alertmanager payload into an All Quiet incident.

<img />

<Check> Prometheus Alertmanager is now successfully integrated with All Quiet, following the detailed setup and verification steps provided.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Prometheus.tf) the default mapping of the `allquiet_integration_mapping` resource for the Prometheus integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# PRTG Network Monitor
Source: https://docs.allquiet.app/integrations/inbound/prtg

Connect PRTG with All Quiet

<Info>Setup time: 3 Min</Info>

Integrate PRTG Network Monitor with All Quiet in a matter of minutes. With webhooks, you can automatically send alerts from PRTG directly to All Quiet, streamlining your team's incident management process.

## 1. Create PRTG Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select PRTG as the integration's type

1. Enter a `Display Name` for your integration, e.g. "PRTG".
2. Select a `Team`.
3. Select `PRTG` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet Webhook URL

After creating the integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on PRTG.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure the Integration with PRTG

Once you've set up an integration of type "PRTG" with All Quiet, it takes only two more steps in your PRTG account to finish off your setup.

### Set up the Notification Template

Sign in to your PRTG Account.
We first need to create a Notification Template that allows us to connect PRTG with All Quiet.

1. From the home screen, click on `Setup`
2. Select `Account Settings`
3. Open `Notification Templates`

<img />

Click `Add Notification Template`.

<img />

Now it's time to define the template

1. Give your notification template a `Name`, e.g. `All Quiet`.
2. Activate the `Execute HTTP Action` toggle.
3. As `URL`, paste in the All Quiet Webhook URL you've obtained in step [Get the All Quiet Webhook URL](/integrations/inbound/prtg#get-the-all-quiet-webhook-url).
4. Make sure the HTTP Method is `Post` and paste in the following `Payload`.

```
colorofstate=%colorofstate&company=%company&comments=%comments&commentssensor=%commentssensor&commentsdevice=%commentsdevice&commentsgroup=%commentsgroup&commentsprobe=%commentsprobe&coverage=%coverage&cumsince=%cumsince&date=%date&datetime=%datetime&device=%device&deviceid=%deviceid&down=%down&downtime=%downtime&group=%group&groupid=%groupid&history=%history&home=%home&homem=%homem&host=%host&iconofstate=%iconofstate&lastcheck=%lastcheck&lastdown=%lastdown&lastmessage=%lastmessage&lastup=%lastup&lastvalue=%lastvalue&linkprobe=%linkprobe&linkgroup=%linkgroup&linkdevice=%linkdevice&linksensor=%linksensor&location=%location&message=%message&name=%name&nodename=%nodename&shortname=%shortname&prio=%prio&priority=%priority&probe=%probe&probeid=%probeid&programname=%programname&programversion=%programversion&sensor=%sensor&sensorid=%sensorid&server=%server&serviceurl=%serviceurl&settings=%settings&since=%since&sitename=%sitename&state=%state&statesince=%statesince&status=%status&summarycount=%summarycount&syslogerrors=%syslogerrors&syslogmessages=%syslogmessages&syslogwarnings=%syslogwarnings&systemdatetime=%systemdatetime&time=%time&timezone=%timezone&toaddress=%toaddress&traperrors=%traperrors&trapmessages=%trapmessages&trapwarnings=%trapwarnings&uptime=%uptime&elapsed_lastcheck=%elapsed_lastcheck&elapsed_lastdown=%elapsed_lastdown&elapsed_lastup=%elapsed_lastup&laststatus=%laststatus&objecttags=%objecttags&parenttags=%parenttags&tags=%tags
```

5. Click `Create`to save the Template.

<img />

<Check>You successfully set up the Notification Template. Next, we need to connect this template with your PRTG to your Monitors to automatically forward alerts to All Quiet.</Check>

### Adjust the Notification Trigger

1. In the navigation, open the `Devices` section
2. Open the `Overview`
3. Select the `Root` module
4. and open `Notification Triggers`

<img />

Create the following Notification Triggers. Of course, the intervals are subject to your preference.

<Tip> We recommend to make use of the option repeat every x minutes.</Tip>

<img />

<Check> You're ready to go. If you set up your integration this way, PRTG Network Monitor alerts will automatically create and update All Quiet incidents.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/PRTG.tf) the default mapping of the `allquiet_integration_mapping` resource for the PRTG Network Monitor integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Rollbar
Source: https://docs.allquiet.app/integrations/inbound/rollbar

Connect Rollbar to All Quiet

<Info>Setup time: 2 Min</Info>

Integrate Rollbar into All Quiet by using our custom integration.

## 1. Add Rollbar Integration to Your All Quiet Team

### Create a Rollbar integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Rollbar as the Integration's Type

1. Enter a `Display Name` for your integration, e.g. "Rollbar".
2. Select a `Team`.
3. Select `Rollbar` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet webhook URL

After creating the integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the integration on Rollbar's website.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Create a custom integration on Rollbar

Sign in to your Rollbar Account.

1. Open `Projects`
2. Select the project you would like to add our integration to. Then click on `+`.

<img />

Our integration can be added via `Webhook`.

<img />

1. As `URL`, paste in the All Quiet webhook URL you've obtained in step [Get The All Quiet Webhook URL](/integrations/inbound/rollbar#get-the-all-quiet-webhook-url).
2. Click `Enable Webhook Integration`.

<img />

After the integration is created, you will receive as success message. Then, do the following:

1. Delete the `Deploy -> Post to Webhook` rule that is auto-created. It's not working with us.
2. Click `Save Settings`.
3. `Send Test Notification`.

<img />

Open the All Quiet Web App and navigate to your Rollbar Integration. Open the `Payload Mapping` tab.

1. Find the test payload in the`latest payloads`.
2. Our pre-configured `payload mapping` will transform Rollbar notifications into All Quiet incidents. You can adjust the mapping to your liking anytime.
3. Observe how the mapping transforms the selected Rollbar payload into an All Quiet incident.

<img />

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Rollbar.tf) the default mapping of the `allquiet_integration_mapping` resource for the Rollbar integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>

<Check>Rollbar is now successfully integrated with All Quiet.</Check>


# Salesforce
Source: https://docs.allquiet.app/integrations/inbound/salesforce

Create All Quiet Incidents from Salesforce Cases

To create incidents in All Quiet by creating a case in Salesforce, please set up our [Salesforce Outbound Integration](/integrations/outbound/salesforce), first. <br /> Within the settings of your Outbound Integration, you can enable the option to [create All Quiet Incidents from Salesforce](/integrations/outbound/salesforce#create-all-quiet-incidents-from-salesforce) and use Salesforce as an Inbound Integration, too.


# Sentry
Source: https://docs.allquiet.app/integrations/inbound/sentry

Connect Sentry to All Quiet

<Info>Setup time: 3 Min</Info>

Integrate Sentry into All Quiet by using a Custom Integration

## 1. Create Sentry Integration on All Quiet

### Create a Sentry integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Sentry for the integration's type

1. Enter a `Display Name` for your integration, e.g. "Sentry".
2. Select a `Team`.
3. Select `Sentry` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet webhook URL

After creating the Sentry integration on All Quiet

1. you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on Sentry.
2. By default, the Sentry integration will create incidents for all Sentry resources. If you want to create incidents for only specific Sentry resources, you can modify the [Discard](/essentials/inbound#reserved-and-required-attributes) attribute in the mapping for the specific resource.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Create a custom integration on Sentry

Open your Sentry, click on your Account and navigate to `Organization settings`.

<img />

1. Navigate to `Developer Settings -> Custom Integrations`
2. Click `Create New Integration`.

<img />

1. Choose `Internal Integration`
2. Click `Next`

<img />

1. Enter a name for your integration
2. Paste in the All Quiet webhook URL you've obtained in step [Get The All Quiet Webhook URL](/integrations/inbound/sentry#get-the-all-quiet-webhook-url).

<img />

1. Select `Read` permissions for `Issue & Event`
2. Select `issue` for `Webhooks`
3. Click `Save Changes` to finally create the custom integration
   <img />

<Check>
  Sentry is now successfully integrated with All Quiet. To test if everythoing works as expected you can interact with any issue in Sentry, e.g. "Resolve" or "Reopen" an existing issue.
</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Sentry.tf) the default mapping of the `allquiet_integration_mapping` resource for the Sentry integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# ServiceNow
Source: https://docs.allquiet.app/integrations/inbound/servicenow

Receive ServiceNow incident updates as open or resolved payloads in All Quiet.

<Info>Setup time: 5 Min</Info>

The **ServiceNow Inbound** integration lets ServiceNow drive All Quiet incidents: when your ServiceNow workflow sends payloads, All Quiet can **open** new incidents or **resolve** existing ones to match ServiceNow.

<Tip>
  Use this together with the [ServiceNow Outbound integration](/integrations/outbound/servicenow) to keep All Quiet and ServiceNow incidents in sync in both directions. The outbound side creates and updates ServiceNow from All Quiet; the inbound side applies ServiceNow state to All Quiet.
</Tip>

## What this integration does

* Accepts inbound traffic from ServiceNow (for example when an incident is opened or reaches a resolved state).
* Maps those events to **open** or **resolved** All Quiet incidents according to your configuration.
* Works **on its own** if you only need ServiceNow → All Quiet updates, or **alongside** the outbound integration for full loop synchronization.

## Create ServiceNow Inbound integration

1. In All Quiet, open the `Inbound Integrations` tab.
2. Click `+ Create`.

<img />

1. Enter a **Display Name** (for example `ServiceNow Inbound`).
2. Select a **Team** for this integration.
3. Choose **ServiceNow** as the `integration type`.
4. Click `Create Inbound Integration`.

<img />

### After creating the inbound integration

Open the `ServiceNow Settings` tab of your new ServiceNow inbound integration in All Quiet. You will find two important things:

1. **Find and copy the webhook URL**. You will use this URL in ServiceNow.
2. In ServiceNow, you will need to create a **Business Rule** that runs the script you can download here. This script will ensure each relevant incident change posts to that URL.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## Step 2 — Create a Business Rule in ServiceNow

In ServiceNow, there are multipe ways to navigate to the Business Rules page. We recommend using the Filter navigator (search field, usually top left) and typing "Business Rules".

1. Navigate to **System Definition** → **Business Rules**.
   <Note>If you don't seee Business Rules in the menu, sign in with a user that can create Business Rules (often a admin or someone with business\_rule\_admin / equivalent).</Note>
2. Click **New**.
3. Configure the rule. You need to set the following fields:

| Field        | Value                        |
| ------------ | ---------------------------- |
| **Name**     | `Send Incident to All Quiet` |
| **Table**    | `Incident`                   |
| **When**     | `after`                      |
| **Insert**   | ✅ (enabled)                  |
| **Update**   | ✅ (enabled)                  |
| **Advanced** | ✅ (enabled)                  |
| **Active**   | ✅ (enabled)                  |

This ensures the webhook runs **after** changes are saved.
<Note> You can of course adjust the name of the rule to your liking. Also, the table you are looking for might be called differently than "Incident" in your instance.</Note>

## Step 3 — Add the script

Open the "**Advanced**" Tab of your new Business rule. Paste the script you dowloaded on the [ServiceNow Settings tab](/integrations/inbound/servicenow#after-creating-the-inbound-integration) into the **Script** field.
If you missed it, here it is again:

```script servicenow business rule script theme={null}
(function executeRule(current, previous /*null when async*/) {

    var webhookUrl = 'https://YOUR-ALL-QUIET-WEBHOOK';

    try {
        var rm = new sn_ws.RESTMessageV2();
        rm.setEndpoint(webhookUrl);
        rm.setHttpMethod('post');
        rm.setRequestHeader('Content-Type', 'application/json');

        var payload = {
            source: "servicenow",
            eventType: getEventType(current, previous),
            incident: {
                sys_id: current.sys_id.toString(),
                number: current.number.toString(),
                state: current.state.getValue(),
                state_desc: current.state.getDisplayValue(),
                priority: current.priority.getValue(),
                priority_desc: current.priority.getDisplayValue(),
                urgency: current.urgency.getValue(),
                urgency_desc: current.urgency.getDisplayValue(),
                impact: current.impact.getValue(),
                impact_desc: current.impact.getDisplayValue(),
                short_description: current.short_description.toString(),
                description: current.description ? current.description.toString() : "",
                assigned_to: current.assigned_to.nil() ? "" : current.assigned_to.getDisplayValue(),
                assignment_group: current.assignment_group.nil() ? "" : current.assignment_group.getDisplayValue(),
                service: primaryIncidentService(current),
                updated_at: new GlideDateTime().getDisplayValue(),
                url: normalizeInstanceBase(getInstanceUrl()) + "incident.do?sys_id=" + current.sys_id
            }
        };

        rm.setRequestBody(JSON.stringify(payload));

        var response = rm.execute();
        var status = response.getStatusCode();

        gs.info("All Quiet webhook sent. Status: " + status);

    } catch (ex) {
        gs.error("All Quiet webhook failed: " + ex.message);
    }

    function getEventType(current, previous) {
        if (!previous) return "created";

        if (current.state.changes()) {
            var state = current.state.getDisplayValue().toLowerCase();
            if (state.includes("resolved") || state.includes("closed")) {
                return "resolved";
            }
        }

        return "updated";
    }

    function primaryIncidentService(inc) {
        try {
            if (!inc.cmdb_ci.nil()) {
                var ciName = inc.cmdb_ci.getDisplayValue();
                if (ciName) {
                    return ciName.toString().trim();
                }
            }
            if (inc.isValidField("service_offering") && !inc.service_offering.nil()) {
                var soName = inc.service_offering.getDisplayValue();
                if (soName) {
                    return soName.toString().trim();
                }
            }
            var gr = new GlideRecord("task_ci");
            gr.addQuery("task", inc.sys_id);
            gr.query();
            if (gr.next() && !gr.ci_item.nil()) {
                var taskCiName = gr.ci_item.getDisplayValue();
                if (taskCiName) {
                    return taskCiName.toString().trim();
                }
            }
        } catch (e) {
        }
        return "";
    }

    function getInstanceUrl() {
        return gs.getProperty("glide.servlet.uri");
    }

    function normalizeInstanceBase(base) {
        if (!base) {
            return "";
        }
        return base.charAt(base.length - 1) === "/" ? base : base + "/";
    }

})(current, previous);
```

## Step 4 — Replace the webhook URL

Make sure your replace

`https://YOUR-ALL-QUIET-WEBHOOK`

with your **actual All Quiet webhook URL** ([copied](/integrations/inbound/servicenow#after-creating-the-inbound-integration) from the inbound integration).

## Step 5 — Test the integration

Open any incident in ServiceNow.
You should see the corresponding incident in All Quiet. If you update the incident in ServiceNow (e.g resolve it), you will see the update in All Quiet as well.

### Payload example

This is what All Quiet receives:

```json jsonBody of the payload theme={null}
{
  "source": "servicenow",
    "eventType": "updated",
    "incident": {
      "sys_id": "abc123",
      "number": "INC0010001",
      "state": "2",
      "state_desc": "In Progress",
      "priority": "3",
      "priority_desc": "3 - Moderate",
      "urgency": "2",
      "urgency_desc": "2 - Medium",
      "impact": "3",
      "impact_desc": "3 - Moderate",
      "short_description": "Interaction",
      "description": "Description",
      "assigned_to": "Assignee Name",
      "assignment_group": "",
      "service": "Example Service",
      "updated_at": "2026-03-31 11:08:03",
      "url": "https://yourservicenowinstance.com//incident.do?sys_id=abc123"
  }
```

### How All Quiet correlates incidents

All Quiet uses **`incident.sys_id`** as the primary identifier so updates map to the **same** All Quiet incident over time.

### Default Severity Mapping

Default severity mapping uses ServiceNow `urgency`: 1 – High → Critical, 2 – Medium → Warning, 3 – Low → Minor. You can adjust this mapping in the [payload mapping](/essentials/inbound#reserved-and-required-attributes) anytime.

### Optional improvements

**Only send important updates**

You can reduce noise by adding a **condition** on the Business Rule, for example:

```text theme={null}
current.state.changes() || current.priority.changes()
```

**Add authentication (recommended)**

You can add a header in the script, for example:

```javascript theme={null}
rm.setRequestHeader('Authorization', 'Bearer YOUR_TOKEN');
```

**Custom field mapping**

If your ServiceNow instance uses custom fields, extend the payload object, for example:

```javascript theme={null}
custom_field: current.u_custom_field.toString()
```

<Check>You're ready. All Quiet will now create incidents based on all your ServiceNow alerts.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/ServiceNow.tf) the default mapping of the `allquiet_integration_mapping` resource for the SigNoz integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>

## Troubleshooting

**Nothing happens**

* Ensure the Business Rule is **Active**.
* Open **System Logs** → **All** and look for log lines such as `All Quiet webhook sent`.
* If the rule fails, check for `All Quiet webhook failed` and the error message in the logs.

## Work with ServiceNow Outbound

If you also enable [ServiceNow Outbound](/integrations/outbound/servicenow), All Quiet incidents created or updated from ServiceNow can be reflected back in ServiceNow, and incidents that originate in All Quiet can still be linked to ServiceNow records depending on your forwarding and routing rules.

Incidents that **did not** start in ServiceNow (for example from an observability tool) can still be represented in ServiceNow when outbound is configured—the outbound integration creates and updates ServiceNow incidents from All Quiet regardless of the original source.

## Related

* [ServiceNow Outbound](/integrations/outbound/servicenow) — create and update ServiceNow incidents from All Quiet
* [Inbound Integrations](/essentials/inbound) — payloads, mapping, and behavior
* [Advanced routing](/advanced/routing) — optional rules per integration


# SigNoz
Source: https://docs.allquiet.app/integrations/inbound/signoz

Connect SigNoz with All Quiet

<Info>Setup time: 2 Min</Info>

Easily integrate SigNoz with All Quiet. Automatically forward alerts from SigNoz to All Quiet, streamline your incident response.

## 1. Create SigNoz Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select SigNoz as the integration's type

1. Enter a `Display Name` for your integration, e.g. "SigNoz".
2. Select a `Team`.
3. Select `SigNoz` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet Webhook URL

After creating the integration on All Quiet, you can view the unique All Quiet Webhook URL of your SigNoz integration.
You will require it in step 2 when configuring the custom integration on SigNoz.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure a custom integration with SigNoz

Once you've set up an integration of type "SigNoz" with All Quiet, the next step is to add a new alerting channel to your SigNoz account. This ensures all your SigNoz alerts will be forwarded to All Quiet.

Sign in to your SigNoz Account.

1. Open `Settings`
2. Select the tab `Alert Channels`
3. Click `New Alert Channel`

<img />

It's time to set up the new notification channel.

1. Select a name, e.g. `All Quiet`
2. As type, select `Webhook`
3. As `Webhook URL`, paste in the All Quiet Webhook URL you've obtained in step [Get the All Quiet Webhook URL](/integrations/inbound/signoz#get-the-all-quiet-webhook-url).
4. Test your alerting channel. If successful, you will find a test incident in All Quiet, created by SigNoz (see 2nd screenshot below).
5. Then, save the channel.

<img />

Back in All Quiet, you'll find the incident that got created by the sent test notification.

<img />

<Check>You're ready. All Quiet will now create incidents based on all your SigNoz alerts.</Check>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/SigNoz.tf) the default mapping of the `allquiet_integration_mapping` resource for the SigNoz integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Site24x7
Source: https://docs.allquiet.app/integrations/inbound/site24x7

Connect Site24x7 to All Quiet

<Info>Setup time: 2 Min</Info>

Integrate Site24x7 into All Quiet by using our custom integration.

## 1. Add Site24x7 Integration to Your All Quiet Team

### Create a Site24x7integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Site24x7 as the Integration's Type

1. Enter a `Display Name` for your integration, e.g. "Site24x7".
2. Select a `Team`.
3. Select `Site24x7` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet webhook URL

After creating the integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the integration on Site24x7's website.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Create a custom integration on Site24x7

Sign in to your Site24x7 Account.

1. Open the `Admin` area.
2. Select the `Third-Party Integrations` menu item.

<img />

Our integration can be added via `Webhooks`.

<img />

1. Select an `Integration Name`, like "All Quiet".
2. As `Hook URL`, paste in the All Quiet webhook URL you've obtained in step [Get The All Quiet Webhook URL](/integrations/inbound/site24x7#get-the-all-quiet-webhook-url).
3. As `HTTP Method`, select "POST" and activate `Post as JSON` and `Send Incident Paramenters` checkboxes. If you like to, you can also add `Send Custom Parameters`.
4. For `Accessibility`, select "Global".
5. As `Authentification Method`, select `Basic / NTLM`. No `User Name` or `Password` required.
6. `Integration Level`: Select, from which Monitors you would like to send information to All Quiet. Here, we selected `All Monitors`.
7. For `Tags to Be Sent With Alerts` and `Alternate Notification`, you can go ahead and customize your case. Here, we selected the default settings.
8. `Trigger Alerts for Monitor Status Change`: Select the type(s) of status change(s) you'd like to trigger an All Quiet alert with.
9. `Save` the webhook.

<img />

After the integration is created, you can

1. test it by triggering a test alert.
2. Next, you will be informed if the test was successful or not.

<img />

Open the All Quiet Web App and navigate to the "Incidents" overview. You will see the test incident created by Site24x7.

<img />

<Check>Site24x7 is now successfully integrated with All Quiet.</Check>

<Tip>As always, you can customize your All Quiet incident triggered via Site24x7 by mapping the payload sent to All Quiet with an All Quiet incident in the [integration's details page](/integrations/inbound/site24x7#get-the-all-quiet-webhook-url).</Tip>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our \[payload mapping documentation]\(Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Site24x7.tf) the default mapping of the `allquiet_integration_mapping` resource for the Site24x7 integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Slack
Source: https://docs.allquiet.app/integrations/inbound/slack

Create Incidents from Your Slack Workspace

<Tip>To create incidents in All Quiet using Slack, please set up our [Outbound Integration for Slack](/integrations/outbound/slack), first. <br /> Then, you can use the command `/aq new` to [create new incidents via your connected Slack Channels](/integrations/outbound/slack#aq-new).</Tip>


# Splunk
Source: https://docs.allquiet.app/integrations/inbound/splunk

Connect Splunk Observability with All Quiet

<Info>Setup time: 3 Min</Info>

Integrate Splunk Observability with All Quiet in a matter of minutes. With webhooks, you can automatically send alerts from Splunk directly to All Quiet, streamlining your team's incident management process.

## 1. Create Splunk Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Splunk as the integration's type

1. Enter a `Display Name` for your integration, e.g. "Splunk".
2. Select a `Team`.
3. Select `Splunk` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet Webhook URL

After creating the integration on All Quiet, you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on Splunk.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure the Integration with Splunk

Once you've set up an integration of type "Splunk" with All Quiet, the next crucial steps involve configuring a splunk search for specific log entries to define a notification and connecting it with All Quiet via the Webhook URL.

First, you need to sign in to your Splunk Account.

1. From the home screen, navigate to `Search & Reporting`.

<img />

In the search tab

1. Create a search for search entries you want to use to create an All Quiet incident under specific circumstances.
2. Find the search results, below.
3. Click `Save as`
4. Select Save as `notification`.

<img />

1. Define a `Title` for a notification. Optionally, you can add a description.
2. Select the permissions.
3. Define the `Notification Type`.
4. Based on the `Notification Type`, you can define a `Trigger`.
5. Add a `Webhook` as `Trigger action`.
6. As `URL`, paste in the All Quiet Webhook URL you've obtained in step [Get the All Quiet Webhook URL](/integrations/inbound/splunk#get-the-all-quiet-webhook-url).
7. Save the notification.

<img />

Next, make sure to add the target URL (the All Quiet Webhook URL) to your Splunk webhook allow list to enable sending incidents to All Quiet. For more information, please refer to the [Splunk documentation](https://docs.splunk.com/Documentation/SplunkCloud/9.3.2411/Admin/ConfigureWebhookAllowList).

<Check> You're ready to go. If you set up your integration this way, Splunk will send alerts to All Quiet.</Check>
<Tip>By configuring additional notifications for other searches, you can trigger All Quiet incidents for various scenarios using the same Webhook URL and Splunk integration.</Tip>
<Info>Unfortunately, Splunk notifications do not fire resolve events.</Info>

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Splunk.tf) the default mapping of the `allquiet_integration_mapping` resource for the Splunk integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# StatusCake
Source: https://docs.allquiet.app/integrations/inbound/statuscake

Integrate your StatusCake Monitors with All Quiet

<Info>Setup time: 5 Min</Info>

Upgrade your StatusCake Monitors with All Quiet. Set escalation policies seamlessly, notify the right people for all alerts.

## 1. Create StatusCake Integration on All Quiet

### Create a StatusCake integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select StatusCake as the integration's type

1. Enter a `Display Name` for your integration, e.g. "StatusCake".
2. Select a `Team`.
3. Select `StatusCake` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet webhook URL

After creating the integration on All Quiet, you can view and copy the URL of the newly generated webhook. You will require this URL in step 2 when configuring the webhook integration on StatusCake.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure StatusCake

The following steps will be done on the StatusCake platform. First, log in to StatusCake with your account.

### Create New Contact Group

On StatusCake, we need to create a new `Contact Group` to forward StatusCake alerts to your new integration in All Quiet

1. In the sidebar select `Contact Groups`.
2. Click `New Contact Group`.

<img />

1. Give your new `Contact Group` a decent name, like "All Quiet".
2. In the `Webhook URL` field, enter the webhook URL that you [generated in step one](/integrations/inbound/statuscake#get-the-all-quiet-webhook-url) of the All Quiet integration setup.
3. As `Webhook Request Method`, select "POST".
4. Test your Wehook. If the test is succesful, you will see a 200 HTTP status code below. Also, you should see a `Resolved` incident in All Quiet, created from your new `StatusCake` integration.
5. `Save Contact Group`.

<img />

### Send Alerts to All Quiet

To send real alerts to All Quiet, add the `Contact Group` you created in the last step to your StatusCake `Uptime Tests`.

1. Click on `Uptime Tests`
2. Select an Uptime Test and click on the `Edit` "Action".

<img />

1. In the `Alerts & Notification` section, add your newly created [Contact Group](/integrations/inbound/statuscake#create-new-contact-group).
2. Click `Save Now`.

Repeat this for all `Uptime Tests` you want to forward to All Quiet.

<img />

<Check> StatusCake monitors are now integrated with All Quiet, enhancing your website's monitoring and alert management capabilities through our easy-to-use platform and mobile apps.</Check>

## Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/statuscake.tf) the default mapping of the `allquiet_integration_mapping` resource for the UptimeRobot integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Twilio
Source: https://docs.allquiet.app/integrations/inbound/twilio

Receive inbound calls and route them to on-call users with All Quiet's Live Call Routing

<Info>
  This documentation explains you how to get a Twilio number and connect it with All Quiet.<br /><br /> Already have a Twilio number connected to your All Quiet account and want to set up live call routing? See **[Live Call Routing](/advanced/live-call-routing)**.
</Info>

## Step 1: Buy a two-way phone number in Twilio

In Twilio, purchase a phone number that can both **receive inbound calls** and be used for **call routing** (outbound calling).

<Warning>
  Buy a phone number from the **country / region you plan to route calls to**. This typically maximizes the chance that calls connect successfully (and reduces unexpected carrier restrictions or formatting issues).<br /><br />
  Ensure the number is **two-way** (supports **inbound & outbound** calling). Live Call Routing needs a number that can receive calls and route them onward.
</Warning>

### How to buy the number

1. In [Twilio Console](https://console.twilio.com/), go to **Phone Numbers** or **Numbers and Senders**.
   <Tip>In case you already have a Twilio account and want to use it for Live Call Routing, you can use the same account. However, we recommend creating a new Twilio Account for Live Call Routing. This way, you can use the Live Call Routing account for call routing only and keep your existing account for other purposes. This means you will also only give All Quiet access to the Live Call Routing account when adding the API credentials to the Twilio integration in All Quiet in [step 2](/integrations/inbound/twilio#step-2-create-the-twilio-integration-in-all-quiet).</Tip>
2. Choose **Buy a number**.
3. Search for a number in the destination **country/region**.
4. Ensure the number supports **Voice** (and your inbound & outbound calling capabilities).
5. Complete the purchase.

### Make sure the number is activated and works

Before connecting it to All Quiet, confirm that the number is active and reachable.

**Recommended quick test**

1. Call the new Twilio number from a real phone.
2. In Twilio Console, open **Monitor → Logs → Calls** (Call Logs).
3. Confirm that your test call shows up and is marked as received.

<Info>If the call does not appear in the logs, the issue is usually outside All Quiet (for example number not fully provisioned, wrong region, carrier restrictions, or account configuration). Make sure to check your Twilio account settings and the number's capabilities.</Info>

## Step 2: Create the Twilio integration in All Quiet

<Info> In All Quiet, Live Call Routing is only available for the **Pro** and **Enterprise** plan. Call Routing Numbers can be created by **Organization Administrators** and **Organization Owners** only. **Team Administrators** can edit existing numbers whose **Root Team** is a team they administer — but cannot create new ones.</Info>

Now connect the Twilio number to All Quiet so it can be used as a **Call Routing Number**.

In the All Quiet Web App

1. Go to the **Call Routing Numbers** tab
2. Click on **+ Create** in the top right corner.

<img />

1. Select a `Display Name` for the number. You can use the actual phone number as the `Display Name`, but we recommend combining it with a descriptive name to make it easier to identify.
2. Select the **Root Team** of the integration. **Organization Administrators** and **Organization Owners** can select from teams within any organization they have access to.

<Info>
  The selected `Root Team` is the **default team** for this number. Later — depending on your permissions — you can route calls to other teams within that team's organization. **Team Administrators** can edit numbers for teams they administer and select those teams in route settings; **Organization Administrators** and **Organization Owners** can select from all teams in the organization.
</Info>

3. Select **Twilio** as the integration `Type`..
4. Click **Create Call Routing Number**.

<img />

### Fill in the Twilio credentials on the Twilio settings page

After creating the integration, you are forwarded to the `Twilio Settings` tab of your new Call Routing Number in All Quiet.

To connect your Twilio number to All Quiet, you need to provide the following values from your Twilio account:

1. **API Base Domain**: Use your Twilio API base domain (default is the **US API** domain).
   * **Where to find it**: In Twilio Console navigate to **Numbers & Senders** > **Phone Numbers**, than select your phone number.
     * In the **Regional** tab, check your phone number's **active region**.
     * For United States (US1) region, the API base domain is `https://api.twilio.com`. For other regions, follow [this guide](https://www.twilio.com/docs/global-infrastructure/create-an-outbound-call-via-rest-api-in-a-non-us-twilio-region) to find the correct API base domain.
2. **Account SID**: Enter your Twilio Account SID (starts with `AC...`).
   * **Where to find it**: In Twilio Console open **Settings** > **Account Settings** and look for the **Account SID** starting with `AC...`
3. **Auth Token**: Enter the auth token for the Account SID above.
   * **Where to find it**: In Twilio Console open **Settings** > **Account Settings** > **API key & auth tokens** and open the **auth tokens** tab and look for the **Primary Auth Token** for the respective **Account SID**.
4. **Phone number**: Select/enter the phone number you bought and verified in [Step 1](/integrations/inbound/twilio#step-1-buy-a-two-way-phone-number-in-twilio).
   <Tip>Check the number’s **Voice configuration** in Twilio (for example under **A call comes in**). All Quiet **automatically overrides Twilio’s demo webhook**, but **does not override other webhooks** you may have configured. Remove any non-demo webhook first—otherwise inbound calls may still be handled by your existing Twilio setup instead of All Quiet.</Tip>

<img />

<Check>Once saved, your Twilio number is connected to All Quiet and ready to be used for Live Call Routing. You will see that the connection is valid if there's a green checkmark at the top of the page.</Check>

<img />

<Tip>
  You've successfully set up your Twilio number and connected it with All Quiet.<br />
  **Next:** Use this number to set up **[Live Call Routing](/advanced/live-call-routing)**.
</Tip>


# UptimeRobot
Source: https://docs.allquiet.app/integrations/inbound/uptimerobot

Integrate your UptimeRobot Monitors with All Quiet

<Info>Setup time: 5 Min</Info>

Upgrade your UptimeRobot alerts with All Quiet. Take action on alerts and set escalation policies seamlessly.

## 1. Create UptimeRobot Integration on All Quiet

### Create a UptimeRobot integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select UptimeRobot for the integration's type

1. Enter a `Display Name` for your integration, e.g. "UptimeRobot".
2. Select a `Team`.
3. Select `UptimeRobot` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet webhook URL

After creating the webhook integration on All Quiet, you can view and copy the URL of the newly generated webhook. You will require this URL in step 2 when configuring the webhook integration on UptimeRobot.

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure UptimeRobot

The following steps will be done on the UptimeRobot platform. So, log in to UptimeRobot with your account.

### Install Webhook integration

1. In the sidebar select `Integrations & API`
2. Scroll down to `Webhook` and select it.

This opens and Overlay called `Add Webhook integration`.

1. In the `Webhook URL` field, enter the webhook URL that you [generated in step one](/integrations/inbound/uptimerobot#get-the-all-quiet-webhook-url) of the All Quiet integration setup.
2. "Send default variables": Select "As query string of webhook URL" toggle.
3. Select which events you would like to be notified about via the webhook.
4. Save your new webhook integration by clicking "Create integration".

### Test your setup

Now, it's time to test your setup by sending a notification to All Quiet. This will help you inspect the payload that UptimeRobot sends and eventually map it to an incident on All Quiet.

Here's how to do it:

1. Select one of your Monitors
2. Click on `Test Notification`.
3. Select `Send to attached integrations` toggle and click on `Send test notifications`

<img />

## 3. Map UptimeRobot payload to All Quiet incident

Great news, we're almost finished with setting up your UptimeRobot integration! To complete the process, navigate back to All Quiet and open the `Payload Mapping` tab of the integration that you've just created.

1. Find the test notification sent from UptimeRobot in the previous step in the`latest payloads`.
2. Our pre-configured `payload mapping` will transform UptimeRobot alerts into All Quiet incidents. You can adjust the mapping to your liking anytime.
3. Observe how the mapping transforms the selected UptimeRobot payload into an All Quiet incident.

<img />

<Check> UptimeRobot monitors are now integrated with All Quiet, enhancing your website's monitoring and alert management capabilities through our easy-to-use platform and mobile apps.</Check>

### Adjust Payload Mapping

For detailed guidance on payload mapping, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/UptimeRobot.tf) the default mapping of the `allquiet_integration_mapping` resource for the UptimeRobot integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Webhook
Source: https://docs.allquiet.app/integrations/inbound/webhook

Connect any Webhook to All Quiet using `cURL`

<Info>Setup time: 7 Min</Info>

Effortlessly integrate webhooks with All Quiet using `cURL` requests. This guide offers practical implementation steps for seamless data transfer between systems.

## Create Webhook Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select UptimeRobot for the integration's type

1. Enter a `Display Name` for your integration, e.g. "Webhook".
2. Select a `Team`.
3. Select `Webhook` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Get the All Quiet webhook URL

After creating the webhook integration on All Quiet

1. you can view and copy the URL of the newly generated webhook. You can now create All Quiet incidents by sending `cURL` and other requests to this unique URL.
2. Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads:
   * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
   * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.
   * If both are enabled, the request must pass both checks to be accepted.

<img />

## Send POST with cURL

The Webhook accepts all HTTP Verbs and supports the following values for the HTTP header `Content-Type` :

* `application/json` maps to property `jsonBody`
* `application/x-www-form-urlencoded` maps to property `formBody`
* `multipart/form-data` maps to property `formBody`
* `text/plain` maps to property `textBody`
* `text/xml`, `application/xml` and `application/xhtml+xml` map to property `xmlBody`

Use the CURL command below as an example to trigger the webhook.

```CURL theme={null}
curl -X POST 'https://allquiet.app/api/webhook/YOUR-WEBHOOK' \
-H 'Content-Type: application/json' \
-d '{"alertName": "Demo Alert", "alertStatus": "firing", "description": "This is a Demo Alert"}'
```

## Inspect your Webhook payload.

Once the cURL command has been executed, the corresponding payload will be visible on your integration's details page.

1. To view a specific payload, click the "Select" button next to the desired entry under "Latest payloads". This action will load the payload into the "Request Payload Example" section for review.
2. The "Selected Payload" field displays the actual payload generated by triggering the Webhook.

<Tip>The JSON content within the `Selected Payload` field can be temporarily edited to test different scenarios.</Tip>

<img />

## Configure Attribute Mapping

If the payload has not been modified from the previous cURL example, the webhook's default attribute mapping should seamlessly translate the data into an All Quiet incident.

1. See how the mapping adds the `alert_desc` field from the payload to the All Quiet incident attribute `Description`.
2. Observe how the mapping transforms the whole selected payload into an All Quiet incident.

<img />

### More about Payload Mapping

For detailed guidance on `Payload Mapping`, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Webhook.tf) the default mapping of the `allquiet_integration_mapping` resource for the Webhook integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>

<Check>Your webhook is now seamlessly integrated with All Quiet through `cURL`, optimizing automated data flow and system performance.</Check>


# All Quiet Website / HTTP Monitor
Source: https://docs.allquiet.app/integrations/inbound/website-http-monitoring

Use our HTTP Monitor to check your websites health

<Info>Setup time: 2 Min</Info>

Set up our All Quiet HTTP Monitor to ping your website anytime. The monitor is set up within a few clicks. After setting it up, we'll create incidents to inform you if anything is wrong.

## 1. Create All Quiet Website / HTTP Monitor

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Website / HTTP Monitor as the integration's type

1. Enter a `Display Name` for your integration, e.g. "HTTP Monitor".
   <Tip>Pick a name that makes it obvious which website the HTTP monitor belongs to.</Tip>
2. Select a `Team`.
3. Select `Website / HTTP Monitor` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

## 2. Configure your Website / HTTP Monitor

Once you've set up the "Website / HTTP Monitor", it's time to configure it. This can be done on the the integration's page.

1. Select your Method (`HEAD`, `GET`, `POST`, `PUT`, `DELETE` or `PATCH`)
2. Enter the URL you want to Monitor. If you want to monitor different URLs, simply set up several monitors.
3. Optionally, you can define `Accepted Status Codes`. If empty, 2xx status codes are accepted. If specified, only the specified status codes are accepted and other status codes trigger an incident.
4. Optionally, you can add Headers in JSON format.
5. Select your Authentification method (`None`, `Basic` or `Bearer`).
6. `Interval`: Select how often the monitor should be triggered.
7. Select the `Timeout`, the duration after which the monitor should time out and considered to be failed.
8. Select how often the Monitor should `retry` the request before creating an incident if something is wrong.

<Note>
  Retries happen inside a single check, not across intervals. With Max Retries = 5, All Quiet does 1 initial request + up to 5 retries (6 attempts total). Each attempt uses the Timeout (e.g. 5s). Between failed attempts there is only a short backoff (tens to hundreds of ms), not another full timeout wait.
</Note>

9. Optionally, you can add a `Content Test` to check if the response contains a specific string in addition to the desired status code.
   * You can select between `Contains`, `Does not contain`, `Matches Regex` or `Does not match Regex` as the `Content Test Mode`.
   * You can enter the text or Regex pattern to test for.
10. If you want to, you can **log the response body** if an incident is created. The monitor will append the response body to the incident. This can be useful to debug issues.
11. Optionally, you can ignore non-HTTP errors, like timeouts that can occur due to internet issues.
12. You may add the number of days until your SSL certificate expires that should set your monitor to `Degraded`. The monitor will be degraded if the certification's expiration is closer than this value.
13. You may add the number of days until your SSL certificate expires that should set your monitor to `Down`. The monitor will be down if the certification's expiration is closer than this value. This makes sure we notifiy you and you won't miss the expiration.
14. Select the **severity** of incidents triggered for `Degraded` monitor results.
15. Select the **severity** of incidents triggered for `Down` monitor results.
16. To finish your setup, click `Save Monitor Settings`.

<Info>You can always pause your monitor by activating the toggle at the top of the settings and saving. </Info>

<img />

<Check>Your monitor is now set up, configured and running.</Check>

### Test your Monitor

We recommend testing your monitor after setting it up to see if it works as expected.
After saving the monitor,

1. Click "Execute" in the `Last Response` section.
2. You'll find the result below. Here, the monitor fails...

<img />

### Outbound IP Addresses

The outbound IP addresses used for HTTP monitoring are dynamic and can be retrieved from the following endpoints:

* US Region: [https://allquiet.app/api/public/v1/metadata/ips](https://allquiet.app/api/public/v1/metadata/ips)
* EU Region: [https://allquiet.eu/api/public/v1/metadata/ips](https://allquiet.eu/api/public/v1/metadata/ips)

While these IP addresses are generally stable, we do not guarantee their persistence. It's recommended to regularly check these endpoints for any changes.

### Incident creation from Monitor

If the monitor fails, you will see that in the results...

<img />

...as well as in your incidents overview. An All Quiet incident is created from your HTTP Monitor.

<img />

### How HTTP Monitoring Status Handling Works

When HTTP monitoring checks a target, the system compares the new status with the most recent one. If the status has changed (for example, from Up to Down or from Down to Up), the system processes the result fully. This includes updating records, sending notifications, and managing incidents.

If the status remains the same (for example, Up to Up or Down to Down), the system stops early without further processing. This prevents duplicate alerts and avoids unnecessary incident creation. You can also see this in the `Response Logs` at the bottom of the `HTTP Monitor Settings` page. The reponse logs will only show one entry per status change, but will update the timestamp based on the last response for the given status.

This behavior differs from other inbound integrations, which create a new incident whenever an alert is received if there is no open incident yet. HTTP monitoring is designed to reduce noise by only acting when a real status change occurs.

<img />

<Tip> If you close an incident manually and the status has not changed, the system will not create a new incident for the same issue. This helps you stay focused on real changes, reduces unnecessary noise, and keeps incident management cleaner.</Tip>


# Zabbix
Source: https://docs.allquiet.app/integrations/inbound/zabbix

Connect Zabbix Monitoring with All Quiet

<Info>Setup time: 5 Min</Info>

Integrate Zabbix with All Quiet in a matter of minutes. With webhooks, you can automatically send alerts from your Zabbix monitoring directly to All Quiet, streamlining your team's incident management process.

## 1. Create Zabbix Integration on All Quiet

Sign in to your All Quiet account.

### Create Integration

1. Click on the `Inbound Integrations` tab.
2. Click on `+ Create`.

<img />

### Select Zabbix as the integration's type

1. Enter a `Display Name` for your integration, e.g. "Zabbix".
2. Select a `Team`.
3. Select `Zabbix` as the integration's type.
4. Click `Create Inbound Integration`.

<img />

### Copy Webhook URL and Download Media Type

After creating the integration on All Quiet

1. you can view and copy the webhook URL. You will require this URL in step 2 when configuring the custom integration on Zabbix.
2. you can view the `Zabbix Media Type` file that you will need to upload in Zabbix in step 2. Download it.
   <Tip> The Media Type we provide works with Zabbix version 7.0 and newer. </Tip>

<img />

<Info>
  Optionally toggle `Enable additional Authentication & Security` below the webhook URL to restrict who can POST payloads.

  * **IP Filter** — Allow requests only from specific IPs or CIDR ranges. Failed checks return **404 Not Found**.
  * **Bearer authentication** — Require `Authorization: Bearer YOUR_TOKEN`. Missing or invalid tokens return **401 Unauthorized**.

  If both are enabled, the request must pass both checks to be accepted.
</Info>

## 2. Configure the Integration with Zabbix

Once you've set up an integration of type "Zabbix" with All Quiet, the next crucial steps involve configuring a Zabbix user, connecting it with All Quiet via the Media Type and Webhook and adding it to the correct user group to be able to send alerts to All Quiet.

First, you need to sign in to your Zabbix Account.

### Create Macro

We create a macro to always include the URL of the Zabbix alert in the related All Quiet incident.

1. Open `Administration`
2. `Macros`
3. Add Macro for \{\$ZABBIX.URL}. As `Value`, enter your Zabbix frontend URL (https\://...)
4. Click `Update` to save the macro.

<img />

### Add All Quiet Media Type

Now, we add the All Quiet Media Type.

1. Open `Alerts`
2. `Media Types`
3. Select `Import`

<img />

1. Select the media type file you downloaded in [step 1](/integrations/inbound/zabbix#copy-webhook-url-and-download-media-type).
2. Click `Import`

<img />

You successfully added the media type.
<Tip>You can [customize the fields](/integrations/inbound/zabbix#optional:-extend-the-zabbix-media-type-xml-file) of this Media Type at any time. Note that testing the Media Type will not work as Zabbix is not substituting variables in the Test cases. To test your Zabbix integration with All Quiet, follow & finish this setup guide.</Tip>

#### Optional: extend the Zabbix Media Type XML File

If you notice that important information is missing in All Quiet, you can adjust the Zabbix **Media Type XML** to include additional parameters/macros, and then map them in All Quiet.

**1. Add parameters to the Zabbix 7.0 media type XML**

For example, you may want to add the host group to the payload. Add this parameter inside the `<parameters>` section of the Media Type:

```xml theme={null}
<parameter>
  <name>TRIGGER.HOSTGROUP.NAME</name>
  <value>{TRIGGER.HOSTGROUP.NAME}</value>
</parameter>
```

For Zabbix **7.0**, the correct built-in macro name is **`{TRIGGER.HOSTGROUP.NAME}`** for trigger notifications/webhooks.

**2. Map it in All Quiet via payload mapping**

Once Zabbix starts sending it, the inbound webhook JSON will contain:

`jsonBody["TRIGGER.HOSTGROUP.NAME"]`

In All Quiet’s mapping UI, map it using this JSONPath:

`$.jsonBody['TRIGGER.HOSTGROUP.NAME']`

You can map this into any All Quiet attribute you want to populate (for example a custom attribute you use for routing), without changing backend defaults.

### Create All Quiet User

Now, it's time to create the All Quiet user.

1. Select section `Users`
2. Again, `Users`
3. Click `Create User`

<img />

1. Add a `Username`, e.g. "All Quiet" and create a password.
2. Add the User to one of your User Groups have that read permissions for the host(s) you want to connect with All Quiet. We will show you how to do this [later](/integrations/inbound/zabbix#ensure-user-has-sufficient-permissions)
3. Switch to Tab `Media`

<img />

In Tab `Media`, click add Media. This opens an overlay.

1. Select Media Type `All Quiet` to use the Media Type we configured [earlier](/integrations/inbound/zabbix#add-all-quiet-media-type).
2. As "Send to", paste in the All Quiet webhook URL you've obtained in step [Copy Webhook URL](/integrations/inbound/zabbix#copy-webhook-url-and-download-media-type).
3. Click `Add`.

Afterwards, click `Update` to create the user.

<img />

#### Ensure User Has Sufficient Permissions

As said earlier, we need to ensure that the user has sufficient permissions in order to be able to forward incidents to All Quiet.

1. We can check the user's permissions by opening the `Permissions` tab.
2. The user should have at least `Read` permissions for the hosts that should be forwarded.

If your user does not have these permissions, they can be changed on group level.

<img />

To update the permissions of your All Quiet user, edit the related user group(s).

1. Open `Users > User groups`.
2. Open the tab `Host Permissions`
3. You can add / remove hosts
4. Make sure that the permissions are at least on `Read` and click `Update` to save your changes.

<img />

### Create Trigger Action

Now it's time to create a trigger to connect Zabbix alerts with All Quiet, using the user we just created.

1. Open `Alerts > Actions`
2. Select \`Trigger Actions\`\`
3. Create `Action`

<img />

After giving your action a name,

1. open the tab `Operations` and click `Add`
2. in the overlay, make sure to select the `User Group` that you added the All Quiet user to [earlier](/integrations/inbound/zabbix#create-all-quiet-user)
3. As `Media Type`, select "All Quiet".
4. Click `Add`.

<img />

Repeat the steps from `Operations` above for `Recovery operations` (1) and `Update operations` (2). Click `Update` to save.

<img />

<Check> You're ready to go. If you set up your integration this way, Zabbix will send alerts to All Quiet.</Check>

Incidents created from Zabbix alerts will show up in your Incidents overview.

<img />

### Adjust Payload Mapping

Looking to customize the fields of your incidents by adjusting the pre-built payload mapping? Simply head over to the “Payload” tab within your integration and make the necessary edits to the mapping. For detailed guidance, you may check out our [payload mapping documentation](/essentials/inbound#how-does-attribute-mapping-work).

<Tip>Using our Terraform provider? [Download](https://allquiet.app/api/integrations/terraform/default/Zabbix.tf) the default mapping of the `allquiet_integration_mapping` resource for the Zabbix integration. Simply copy the syntax to your .tf file and tailor the resource to your team's needs!</Tip>


# Zapier
Source: https://docs.allquiet.app/integrations/inbound/zapier

Create and Update Incidents in All Quiet Using Zapier Actions

<Tip>Please set up our [Zapier Outbound Integration](/integrations/outbound/zapier), first.
If you want to use Zapier to send All Quiet incidents to other apps, please refer to the outbound documentation, too. **For Pro and Enterprise plan users:** No matter which teams you added when setting up the [outbound integration](/integrations/outbound/zapier#create-outbound-integration), all All Quiet incidents will always be created in the integration's root team.</Tip>

You might want to use our Zapier inbound integration to connect All Quiet to an observability tool that you use but we do not support, just yet. Here, you can find the list of [Server Monitoring tools integrated in Zapier](https://zapier.com/apps/categories/server-monitoring).

Or, like in the example we are going to showcase, you might want to create and update incidents in All Quiet based on Gmail labeling. The options are almost endless.

## Create Incident Action

1. On the home screen, click `Create`.
2. Select `Zaps`.

<img />

After the Zap is created, select the Trigger.

<img />

<Info>In this example, we want to Trigger a new incident via Gmail. Instead of using Gmail, you could also use other Zapier integrations as a Trigger.</Info>

<img />

We want to create the incidents by labeling email, that's why we pick the `New Labeled Email` Event (2) after selecting Gmail as Trigger (1).

<img />

Next, we need to sign in to the Gmail account we want to use to create incidents via labeling.
Here, we already signed in with our support email address.
After sign in, click `Continue`.

<img />

Now, we need to define the actual trigger. Here, we decided to label emails as `Incident` to trigger an All Quiet incident.
After selection, click `Continue`.

<img />

Next, we can see emails that are labeled as `Incident` in our connected Gmail account.

1. We have to select the email we want to use for a test.
2. Then, we can `Continue with the selected record`.

<img />

Now, we need to set up the action we want to trigger with the labeling - the new incident in All Quiet.

<Tip>This has to be done regardless of choosing Gmail or any other integration as a Trigger.</Tip>

1. Search for `All Quiet`.
2. Select it.

<img />

You can select between two different Action types.

1. `Create Incident`
2. `Create Incident Intent`

<Info>For now, we select the `Create Incident` Action. To learn more about `Create Incident Intent` Action, see [Create Incident Intent Action section](/integrations/inbound/zapier#create-incident-intent-action).</Info>

<img />

After selecting `Create Incident` and clicking `Continue`, we need to sign in to our All Quiet Account to connect it with Zapier.

<img />

You will have to provide your

1. Integration ID and
2. Webhook Secret
   that you received after [creating the outbound integration in All Quiet](/integrations/outbound/zapier#create-outbound-integration).
3. Also, provide your `Data Storage Region`, either `US` or `EU`.
4. After providing the credentials, click `Yes, Continue to All Quiet`.

<img />

After signing in with All Quiet, we can continue.

<img />

Next, it's time to define the incident.

<Tip>This has to be done regardless of choosing Gmail or any other integration as a Trigger. The available variables, however, differ by the selected integration and use case.</Tip>

1. Create a `Incident Title`. Here, we use a combination of text and, in this use case, email variables provided by the Gmail Trigger.
2. Define the `Severity` that incidents created by labeling emails as `Incident` should have. Here, we selected "Critical". If you want to have different severities for different mails, you could go ahead and create different labels instead of one `Incident` label.
3. Define the `Attributes` of the incident. Here, we added the Subject & Description of the email.
4. Define the `Status` of the incident. As the incident is created by the labeling, we set the status to `Open`.
5. After configuring the incident, click `Continue.`

<img />

Now, we can test if incident creation works by labeling in Gmail. Click `Test step`.

<img />

Opening All Quiet, we can see that the incident was created as expected.

<img />

Now, we can publish our Zap to use it for automatic incident creation.

<img />

<Check>You have successfully created an All Quiet incident via Zapier.</Check>

## Create Incident Intent Action

Now, we want demonstrate how to create a Zap to update an an existing incident.

<Info>We will keep working with the Gmail Integration to demonstrate a usecase. Feeld free to use any other Zapier Integration that suits your case as a Trigger.</Info>

This Zap will update the status of the incident we created [earlier](/integrations/inbound/zapier#create-incident-action) to `Resolved`, by re-labeling the correonding email in Gmail.

Again, we need to start with setting up the Gmail Trigger. We will not document all steps again, but focus on what's different.

After selecting the "New Labeled Email" Event and the Gmail Account we want to use, we set up a new Trigger to react to emails with the label `Resolved`.

<img />

In Gmail, we already added an email to the label to make sure we have values to test the zap.

1. Select the email we want to use to test.
2. Click `Continue with selected record`.

<img />

Next, we add the All Quiet Action. This time, we select Action Type
`Create Incident Intent` (2) and continue.

<Tip>This has to be done regardless of choosing Gmail or any other integration as a Trigger.</Tip>

<img />

The All Quiet Account is already connected, so we can move on with configuring the Action.

1. We Select an `Incident ID`. Simplest way is you use one of those already provided by the Gmail Trigger.
2. We select our `Intent`. Remember, we want to resolve incidents if the incident triggering mail was re-labeled as `Resolved`.
3. We can add a `Message` that is added to the intent. We stuck to text, here, but you can use variables, too.

`Continue`.

<img />

Click `Test step` to test your Zap.

<img />

Entering All Quiet, you can check if the incidents got updates as expected by looking into the incident details.

<img />

`Publish` the Zap if you liked the result.

<img />

<Check>You have successfully updated an All Quiet incident via Zapier.</Check>


# Confluence
Source: https://docs.allquiet.app/integrations/outbound/confluence

Connect your Confluence Space with All Quiet to effortlessly prepare documentations or retrospectives on incidents.

<Info>Setup time: 2 Min</Info>

Connect Confluence with All Quiet for streamlined post-incident analysis.

## Create Outbound Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Confluence".
2. Select a `Team`. <Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Select `Confluence` as the integration's type.
4. Forwarding settings:
   1. **Default:** `On Forwarding` - Pages will only be created if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Confluence integration that automatically forward incidents in specific scenarios.
   2. **Alternative**: `On Incident Creation` will automatically forward all incidents to Confluence as soon as they are created and create new Confluence pages.
      <Tip>You can change your selection anytime, but we recommend to select `On Forwarding`. We will explain why in the [example](/integrations/outbound/confluence#creating-an-incident-retro-page-in-confluence) below.</Tip>
5. Click `Create Outbound Integration`.

<img />

### Add All Quiet to your Confluence Space

Once you've successfully created your new outbound integration, you'll automatically be redirected to its `Settings` page.

1. Observe that the installation status of the All Quiet integration is still pending.
2. To complete the integration with your Confluence site, click `Add to Confluence`.

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/confluence#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

You'll be redirected to Confluence, where you'll have to login first.

After login, you you’ll need to grant All Quiet permissions for your the Confluence site.
We request only the permissions essential for All Quiet to operate correctly. These permissions are utilized solely when you interact with the app and are never used for any other purpose.

1. If your Atlassian account is linked to more than one Confluence site, select the site you want to connect All Quiet to.
2. Click `Accept`.

<img />

Then, your are redirected back to your Confluence integration's details page in All Quiet.
Next, you need to configure the integration.

1. As you can see, the Installation Status changed to `installed`.
2. Select the Confluence Site you want to forward the All Quiet incidents to. You can only select those sites that you granted All Quiet permission to (see prior step).
3. Select the Confluence space in which you want to create pages based on All Quiet incidents.
4. Select the `Parent Page` for the your incidents' Confluence pages.
5. Make sure to `Save Confluence Settings`, otherwise forwarding will not work.

<img />

<Check> Confluence is now integrated with All Quiet. Depending on your [setup](/integrations/outbound/confluence#add-all-quiet-to-your-confluence-space), All Quiet incidents can now be [forwarded manually](/essentials/incident#forwarding) to your Confluence space or automatically create pages.</Check>

### Creating an Incident Retro Page in Confluence

In the following part, we want to quickly demonstrate how a Confluence page created from an incident can look like.

In the screenshot below, you can find an All Quiet incident.

1. There was some communication going on, and the team agreed to have a Retro for this incident. That's why Mads forwarded it to Confluence.
2. The Confluence page is linked.

<img />

Following the Link to Confluence, you will see this:

1. As defined in my [integration's settings](/integrations/outbound/confluence#add-all-quiet-to-your-confluence-space), the page got created below `Parent Page` "All Quiet Incident Retros"
2. The title of the Confluence page is a combination of the timestamp of the incident's creation and the incident title in All Quiet. Please note that timestamps in the title will always be based on your team's timezone.
3. In this section, you will find the main incident details, as well as a link to the incident in All Quiet (see section headline).
4. This part features all additional incident attributes you previously defined in our [mapping engine](/essentials/inbound#mapping-payloads). Moreover, if there are further links related to the incident, they will be listed here.
5. All events linked to the incident. Basically the communication in All Quiet.
6. The team members that were on-call during each event. Only Tier 1 members and members from higher Tiers that got notified due to escalations are listed.
   <Tip>As the Confluence page is a snapshot of the All Quiet incident, we recommend to activate the [Trigger On Forwarding](/integrations/outbound/confluence#add-all-quiet-to-your-confluence-space) feature for your Confluence integration. That is because when deciding to automatically create the page with incident creation, there won't be a lot history / events available.</Tip>

<img />

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# Discord
Source: https://docs.allquiet.app/integrations/outbound/discord

Connect Your Discord Server with All Quiet to Manage Incidents from Discord.

<Info>Setup time: 4 Min</Info>

Effortlessly connect Discord with All Quiet for streamlined incident management.

## Create Outbound Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Discord".
2. Select a `Team`. <Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Select `Discord` as the integration's type.
4. Forwarding settings:
   1. **Default:** `Always` will automatically forward all incidents to your Discord channels, unless excluded by [advanced routing rules](/advanced/routing).
   2. **Alternative**: `Always After Forwarding` - Messages will only be sent if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Discord integration that automatically forward incidents in specific scenarios. After the initial Forwarding, all updates will automatically be sent.
      <Tip>You can change your selection anytime.</Tip>
5. Click `Create Outbound Integration`.

<img />

### Add All Quiet to Your Server

Once you've successfully created your new outbound integration, you'll automatically be redirected to its `Settings` page.

1. Observe that the installation status of the All Quiet integration is still pending.
2. To complete the integration with your Discord Server, click `Add to Discord`.

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/discord#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

You'll be redirected to Discord, where you'll need to grant permissions to the All Quiet Discord app.

We request only the permissions essential for All Quiet to operate correctly. These permissions are utilized solely when you interact with the app and are never used for any other purpose.

1. Select the servers where you wish to add All Quiet.
2. Click `Continue`.

<img />

In the next step, you need to authorize the All Quiet App to read and write messages in your Discord Server to make full use of the integration.

<img />

After granting All Quiet access to your Discord servers, you'll be redirected back to the integration in All Quiet. Notice that the Installation Status now reads "Installed".

1. For All Quiet to send incidents to your Discord channels, you must select at least one channel.
   <Tip> When selecting a **private channel**, make sure to add the All Quiet App / All Quiet EU App as a member via the Discord channel settings > permissions. </Tip>
2. Click `Save Settings` to confirm your channel selections.

<img />

## Engage with Incidents Directly in Discord

Whenever you engage with incidents via All Quiet, the Discord integration sends an interactive message to your designated channels. This allows for seamless incident management, mirroring the experience of our iOS, Android, and Web Apps, all within Discord.

<Info> If incident grouping is enabled, All Quiet will only include the <b>grouping attributes</b> in the Discord messages we send (the same fields used to group events into an incident). Learn more in our [Inbound Integrations docs](/essentials/inbound#optional-additional-attribute-keys).</Info>

<img />

<Check> Discord is now integrated with All Quiet, streamlining incident management and communication within a familiar interface.</Check>

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# GitHub
Source: https://docs.allquiet.app/integrations/outbound/github

Connect GitHub with All Quiet to create GitHub issues based on All Quiet incidents.

<Info>Setup time: 5 Min</Info>

Effortlessly connect GitHub with All Quiet for streamlined incident management.

<Tip>
  The first part of this documentation focuses on creating the integration. The second explains how to create GitHub issues based on All Quiet incidents (Outbound).
  Want to create new incidents from GitHub (Inbound)? Follow the [third part](/integrations/outbound/github#create-all-quiet-incidents-from-github) of this guideline.
</Tip>

<Warning>
  Currently, you can only install **one** All Quiet integration per GitHub workspace/organization. Choose your All Quiet `Root Team` and the GitHub repository access wisely, as these determine where incidents are created and where issues are synced. Need multiple integrations? Contact [support@allquiet.app](mailto:support@allquiet.app)
</Warning>

## Create Outbound Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "GitHub".
2. Select a `Root Team`. <Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Select `GitHub` as the integration's type.
4. Forwarding settings:
   1. **Default:** `Always After Forwarding` - GitHub issues will only be created if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your GitHub integration that automatically forward incidents in specific scenarios.
   2. **Alternative**: `Always` will automatically forward all incidents to GitHub and create issues, unless excluded by additional [advanced routing rules](/advanced/routing).
      <Tip>You can change your selection anytime.</Tip>
5. Click `Create Outbound Integration`.

<img />

### Add All Quiet to GitHub

Once you've successfully created your new outbound integration, you'll be redirected to its `Settings` page.

1. Observe that the installation status of the All Quiet integration is still pending.
2. Click `Install on GitHub` to authenticate the integration. Make sure you have the necessary GitHub permissions to install the app on the desired repositories.

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/github#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

You are redirected to GitHub where you'll be asked to install the correct GitHub App:

* If you're an `allquiet.app` (US) customer: install the `All Quiet` GitHub App
* If you're an `allquiet.eu` (EU) customer: install the `All Quiet EU` GitHub App

<img />

## Configure Outbound Integration

After granting All Quiet the required access to the desired repositories of your Organization, you are redirected back to your GitHub integration's details page in All Quiet.
Next, configure the integration:

1. Select the GitHub organization and repository you want to create issues in.
2. Configure how new GitHub issues should be created and All Quiet actions should be synced to the GitHub issue.
   * The Initial State for new issues created from All Quiet incidents.
   * Optional: Add labels to new issues created from All Quiet incidents.
   * The GitHub issue status when an incident is resolved.
   * The GitHub issue status when an incident is reopened.
   * Optionally, you can post incident activity as a comment in the GitHub issue.
3. Optionally, configure updates on GitHub issues that sync to All Quiet incidents.
   * GitHub states that resolve incidents in All Quiet.
   * GitHub states that reopen incidents in All Quiet.
4. Make sure to `Save` your settings.

<img />

<Check>
  If you decide to save & stop here, your GitHub Outbound Integration with All Quiet is ready to go. Depending on your [setup](/integrations/outbound/github#create-outbound-integration), All Quiet incidents will now automatically create issues in GitHub or can be [forwarded manually](/essentials/incident#forwarding) to GitHub. The states will be synced based on your selection.
</Check>

## Create All Quiet Incidents From GitHub

This feature is basically the **GitHub inbound integration**. You can create All Quiet incidents from GitHub issues. Here's how it works:

<Tip>
  If you use both inbound and outbound, avoid creating multiple **GitHub inbound** configurations that point to the same GitHub repository. Otherwise, an outbound-created issue can trigger another inbound configuration and accidentally create duplicate incidents or loops. We recommend using **only one inbound integration per GitHub repository**.
</Tip>

<Note>**For Pro and Enterprise plan users:** No matter which teams you added in `Team Connections` when setting up the outbound integration, all All Quiet incidents will always be created in the integration's root team.</Note>

On your GitHub outbound integration’s details page in All Quiet, **scroll below section `Create incidents From GitHub`**

To create incidents from GitHub:

1. Activate `Create on new issue` and / or `Create on issue update`. **Otherwise**, GitHub issues will **not create** new All Quiet incidents **at all**.
   * Enable `Create on new issue`: All Quiet incidents will be created when **creating** a GitHub issue matching the criteria below.
   * Enable `Create on issue update`: All Quiet incidents will be created when **updating an existing** GitHub issue to match the criteria below.
2. Optionally, restrict All Quiet incident creation to GitHub issues that match specific criteria (for example labels and states), depending on your setup.
3. `Save GitHub Settings`.

<img />

<Check>You have successfully enabled the **GitHub inbound integration**. To manage your settings, open your GitHub integration details page.</Check>

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# GitLab
Source: https://docs.allquiet.app/integrations/outbound/gitlab

Connect your GitLab projects with All Quiet to create GitLab work items based on All Quiet incidents.

<Info>Setup time: 5 Min</Info>

Effortlessly connect GitLab with All Quiet for streamlined incident management.

<Tip>All changes All Quiet performs in GitLab are shown as actions of the GitLab user who authenticated the integration. We recommend using a dedicated GitLab account (for example `All Quiet User`) that is not used by a person, so you can clearly distinguish actions from All Quiet vs. actions from your team members.</Tip>

<Tip>
  The first part of this documentation focuses on creating the integration. The second explains how to create GitLab work items based on All Quiet incidents (Outbound).
  Want to create new incidents from GitLab (Inbound)? Follow the [third part](/integrations/outbound/gitlab#create-all-quiet-incidents-from-gitlab) of this guideline.
</Tip>

## Create Outbound Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "GitLab".
2. Select a `Team`. <Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Select `GitLab` as the integration's type.
4. Forwarding settings:
   1. **Default:** `Always After Forwarding` - GitLab work items will only be created if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your GitLab integration that automatically forward incidents in specific scenarios.
   2. **Alternative**: `Always` will automatically forward all incidents to GitLab and create work items, unless excluded by additional [advanced routing rules](/advanced/routing).
      <Tip>You can change your selection anytime.</Tip>
5. Click `Create Outbound Integration`.

<img />

### Add All Quiet to your GitLab workspace

Once you've successfully created your new outbound integration, you'll automatically be redirected to its `Gitlab Settings` page.

1. Observe that the installation status of the All Quiet integration is still `pending`.
2. To complete the integration with GitLab, click on `Add to GitLab` to authenticate the integration.

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/gitlab#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

## Configure Outbound Integration

If oAuth with GitLab is successful, you are redirected back to your GitLab integration's details page in All Quiet.
Next, you need to configure the integration.Í

1. As you can see, the Installation Status changed to `installed`.
2. Select the GitLab namespace / group / project you want to forward All Quiet incidents to (options depend on your GitLab setup).
3. Configure how new GitLab work items should be created (for example work item type, Ílabels and default state).

<img />

As you can manage the incident in both, All Quiet and GitLab, you can sync the state between both projects. This allows you to manage the incident on one platform only and you don't have to make changes twice.

For changes in All Quiet:

1. Select the GitLab work item type you want to create for new All Quiet incidents.
2. Select the initial state for new work items created from All Quiet incidents.
3. Select the GitLab labels you want to add to new work items created from All Quiet incidents.
4. Select the GitLab work item state you want to set after resolving an incident in All Quiet.
5. Select the GitLab work item state you want to set after re-opening an incident in All Quiet.

<img />

For changes in GitLab:

1. Select the GitLab state that sets an incident to `Resolved` in All Quiet.
2. Select the GitLab state that sets an incident to `Reopened` in All Quiet.

Make sure to save your GitLab settings.

<img />

<Check>If you decide to save & stop here, your GitLab Outbound Integration with All Quiet is ready to go. Depending on your [setup](/integrations/outbound/gitlab#create-outbound-integration), All Quiet incidents will now automatically create work items in GitLab or can be [forwarded manually](/essentials/incident#forwarding) to GitLab. The states will be synced based on your selection.</Check>

## Create All Quiet Incidents From GitLab

This feature is basically the **GitLab inbound integration**. You can create All Quiet incidents from GitLab work items. Here's how it works:

<Tip>If you use both inbound and outbound, avoid creating multiple **GitLab inbound** integrations that point to the same GitLab project/namespace. Otherwise, an outbound-created work item can trigger another inbound integration and accidentally create duplicate incidents or loops. We recommend using **only one inbound integration per GitLab project/namespace**.</Tip>

<Note>**For Pro and Enterprise plan users:** No matter which teams you added in `Team Connections` when setting up the [outbound integration](/integrations/outbound/gitlab#add-all-quiet-to-your-gitlab-workspace), all All Quiet incidents will always be created in the integration's root team.</Note>

On your GitLab outbound integration’s details page in All Quiet, **scroll below section `Create Incidents From GitLab`**

To create incidents from GitLab:

1. Activate `Create on new work item` and / or `Create on work item updateÍ`. **Otherwise**, GitLab work items will **not create** new All Quiet incidents **at all**.
   * Enable `Create on new work item`: All Quiet incidents will be created when **creating** a GitLab work item matching the criteria below.
   * Enable `Create on work item update`: All Quiet incidents will be created when **updating an existing** GitLab work item to match the criteria below.
2. Optionally, restrict incident creation to GitLab work items that match specific criteria (for example work item type, state or specific labels), depending on your setup.
3. `Save GitLab` settings.

<img />

<Check>You have successfully enabled the **GitLab inbound integration**. To manage your settings, open your GitLab integration details page.</Check>

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# Google Chat
Source: https://docs.allquiet.app/integrations/outbound/google-chat

Connect Your Google Chat Space with All Quiet to Manage Incidents from Google Chat.

<Info>Setup time: 2 Min</Info>

Integrate your Google Chat Space with All Quiet for efficient incident management right from Google Chat.

Unlike most of our integrations, this setup begins in your Google Chat Space instead of the All Quiet web app. Make sure to be logged in to your All Quiet account as well to make the integration setup as seamless as possible.

## Add All Quiet to your Google Chat Space

If you are a `Space Manager` in Google Chat, ensure you have the necessary permissions to add an app. If not, contact your Google Chat `Space Manager` for assistance.

1. In your Google Chat, open Google Chat Apps.
2. Select the Space you want to connect with All Quiet.
3. Open the drop down menu of the Space and Select `Apps & integrations`.

<img />

Clicke  `+ Add Apps`.

<img />

Search for "All Quiet" (allquiet.eu users need to search for "All Quiet EU").

<img />

Select our app and then press the `Add` button.

<img />

You can view the permissions that All Quiet will request and grant them per clik on `Install app`.

<img />

<Check>You've successfully added the All Quiet app to your Google Chat Space. Now it's time to connect it to All Quiet.</Check>

### Set up Google Chat Integration in All Quiet

After receiving the welcome message in your Google Chat Space, click `Connect` or use the `/connect` command in your space.

<img />

You'll be redirected to All Quiet to create the new [outbound integration](/integrations/outbound) with Google Chat.

1. Give your integration a `Display Name`, e.g. "Google Chat".
2. Select the `All QuietTeam` you want to connect to Google Chat.<Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Click `Create & Connect` to connect All Quiet and Google Chat.

<img />

As you can see, the installation status of the All Quiet integration is now `installed` and it is connected to the Google Chat Space you selected [in the previous step.](/integrations/outbound/google-chat#add-all-quiet-to-your-google-chat-space)

<Info> In the `Edit` tab, you can change general settings like the integration's **Forwarding settings**: <ol><li>**Default:** `Always` will automatically forward all incidents to your Google Chat Space, unless excluded by [advanced routing rules](/advanced/routing).</li><li>**Alternative**: `Always After Forwarding`: Messages will only be sent if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Google Chat integration that automatically forward incidents in specific scenarios. After the initial Forwarding, all updates will automatically be sent.</li></ol> You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. This means you can send incidents from multiple teams to the same Google Chat Space using one integration.</Note>

<img />

<Check> Google Chat is now integrated with All Quiet, simplifying incident management by consolidating notifications and actions in one place.</Check>

## Engage with Incidents Directly in Google Chat

Each time you engage with incidents via All Quiet, the Google Chat integration sends an interactive message to your designated space. This allows you to manage incidents seamlessly, mirroring the experience on our iOS, Android, and Web Apps, all without leaving Google Chat.

<Info> If incident grouping is enabled, All Quiet will only include the <b>grouping attributes</b> in the Google Chat messages we send (the same fields used to group events into an incident). Learn more in our [Inbound Integrations docs](/essentials/inbound#optional-additional-attribute-keys).</Info>

<Info> For compliance reasons, only Users with rights in the All Quiet team(s) connected to the incident can interact with the Message.</Info>

<img />

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.

Want to connect multiple Google Chat Spaces with All Quiet? Create a new integration for each Space you want to connect and connect them to the desired All Quiet team(s).


# Google Docs
Source: https://docs.allquiet.app/integrations/outbound/google-docs

Connect Google Docs with All Quiet to create incident documentation or retrospectives as Google documents.

<Info>Setup time: 2 Min</Info>

Connect Google Docs with All Quiet for streamlined post-incident analysis and shareable write-ups in your Google Workspace.

## Create Outbound Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Google Docs".
2. Select a `Root Team`. <Note>For Organizations with Pro and Enterprise plan: You will be able to add additional teams in the next step.</Note>
3. Select `Google Docs` as the integration's type.
4. Forwarding settings:
   1. **Default:** `On Forwarding` - Google documents will only be created if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Google Docs integration that automatically forward incidents in specific scenarios.
   2. **Alternative:** `On Incident Creation` will automatically forward all incidents to Google Docs as soon as they are created and create new documents.
      <Tip>You can change your selection anytime, but we recommend to select `On Forwarding`. We will explain why in the [example](/integrations/outbound/google-docs#creating-an-incident-document-in-google-docs) below.</Tip>
5. Click `Create Outbound Integration`.

<img />

### Connect Google and configure Google Docs

Once you've successfully created your new outbound integration, you'll automatically be redirected to its `Settings` page.

1. Observe that the installation status of the All Quiet integration is still pending.
2. To complete the integration with your Google account, click `Connect Google` (or the Google sign-in action shown in the product).

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/google-docs#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

After clicking `Connect Google`, you'll be redirected to Google, where you may need to sign in. After sign-in, grant All Quiet the permissions required to create and manage documents on your behalf.
We request only the permissions essential for All Quiet to operate correctly. These permissions are utilized solely when you interact with the app and are never used for any other purpose.

After giving All Quiet the required rights in your Google Workspace, you are then redirected back to your Google Docs integration's details page in All Quiet. Next, configure where new documents should be created.

1. As you can see, the Installation Status changed to `installed`.
2. Select the Google Drive Folder All Quiet should write and add new Google Docs to. You can also navigate to and select subfolders within your Drive by clicking on the underlined title of a folder.
   3Í. Make sure to save your Google Docs settings, otherwise forwarding will not work.

<img />

<Check> Google Docs is now integrated with All Quiet. Depending on your [setup](/integrations/outbound/google-docs#connect-google-and-configure-google-docs), All Quiet incidents can now be [forwarded manually](/essentials/incident#forwarding) to Google Drive as new Google documents, or documents can be created automatically according to your forwarding option.</Check>

### Creating an incident document in Google Docs

The following section describes what a Google document created from an incident typically contains.

1. When the team decides to capture a retro or handoff in writing, an incident can be [forwarded](/essentials/incident#forwarding) to Google Docs. A link to the new document appears on the incident in All Quiet.
2. Click on the link to open the Google Document and to review it.
   <Note>  As defined in your [integration settings](/integrations/outbound/google-docs#connect-google-and-configure-google-docs), the file is created in the folder (or context) you selected in All Quiet. The document title is a combination of the timestamp of the incident's creation and the incident title in All Quiet. Timestamps in the title are based on your team's timezone. Only team members with respective access rights to the Google document / drive folder open the link.</Note>

<img />

In the document you will find:

1. A section with the main incident details and a link back to the incident in All Quiet.
2. Any additional incident attributes you defined in the [mapping engine](/essentials/inbound#mapping-payloads), plus related links when present.
3. The [incident history](/essentials/incident#incident-history), including all events and on-call information until the incident was exported.
   <Tip>Because the Google document is a snapshot of the All Quiet incident, we recommend `On Forwarding` for your Google Docs integration. If a document is created as soon as the incident is opened, there is often little history or event context to include yet.</Tip>

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# Google Sheets
Source: https://docs.allquiet.app/integrations/outbound/google-sheets

Connect Google Sheets with All Quiet to record incident details or retrospectives as rows in a spreadsheet.

<Info>Setup time: 2 Min</Info>

Connect Google Sheets with All Quiet for structured, filterable post-incident records in a spreadsheet your team already uses.

## Create Outbound Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Google Sheets".
2. Select a `Root Team`. <Note>For Organizations with Pro and Enterprise plan: You will be able to add additional teams in the next step.</Note>
3. Select `Google Sheets` as the integration's type.
4. Forwarding settings:
   1. **Default:** `On Forwarding` - Google Sheets will only be created if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Google Sheets integration that automatically forward incidents in specific scenarios.
   2. **Alternative:** `On Incident Creation` will automatically forward all incidents to Google Sheets as soon as they are created and create a new sheet for each incident.
      <Tip>You can change your selection anytime, but we recommend to select `On Forwarding`. We will explain why in the [example](/integrations/outbound/google-sheets#viewing-an-incident-row-in-google-sheets) below.</Tip>
5. Click `Create Outbound Integration`.

<img />

### Connect Google and configure Google Sheets

Once you've successfully created your new outbound integration, you'll automatically be redirected to its `Settings` page.

1. Observe that the installation status of the All Quiet integration is still pending.
2. To complete the integration with your Google account, click `Connect Google` (or the Google sign-in action shown in the product).

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/google-sheets#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

After clicking `Connect Google`, you'll be redirected to Google, where you may need to sign in. After sign-in, grant All Quiet the permissions required to read and update spreadsheets on your behalf.
We request only the permissions essential for All Quiet to operate correctly. These permissions are utilized solely when you interact with the app and are never used for any other purpose.

After giving All Quiet the required rights in your Google Workspace, you are then redirected back to your Google Sheets integration's details page in All Quiet. Next, configure the spreadsheet that should receive incident rows.

1. As you can see, the Installation Status changed to `installed`.
2. Select the Google Drive Folder All Quiet should write and add new Google Sheets to. You can also navigate to and select subfolders within your Drive by clicking on the underlined title of a folder.
3. Make sure to `save` your Google Sheets settings, otherwise forwarding will not work.

<img />

<Check> Google Sheets is now integrated with All Quiet. Depending on your [setup](/integrations/outbound/google-sheets#connect-google-and-configure-google-sheets), All Quiet incidents can now be [forwarded manually](/essentials/incident#forwarding) and recorded in new Google Sheets, or Sheets can be added automatically according to your forwarding option.</Check>

### Creating a Google Sheet for an incident

The following section describes what you typically see when an incident is exported to a new spreadsheet.

1. After discussion in All Quiet, the team may [forward](/essentials/incident#forwarding) the incident to Google Sheets. The incident in All Quiet links to the respective Google Sheet in your Drive.
2. Click on the link to open the Google Sheet and to review it.
   <Note> As defined in your [integration settings](/integrations/outbound/google-sheets#connect-google-and-configure-google-sheets), the incident is written to the Google Drive Folder you selected in All Quiet. The document title is a combination of the timestamp of the incident's creation and the incident title in All Quiet. Timestamps in the title are based on your team's timezone. Only team members with respective access rights to the Google document / drive folder open the link.</Note>

<img />

In that Google Sheet you will usually find:

1. Identifying fields such as the incident title, creation time, and a link to the incident in All Quiet. Timestamps follow your team's timezone where applicable.
2. Main incident details and any additional attributes from your [mapping engine](/essentials/inbound#mapping-payloads), depending on how columns are configured.
3. The [incident history](/essentials/incident#incident-history), including all events and on-call information until the incident was exported.
   <Tip>Because each Google Sheet reflects the All Quiet incident at the time of export and the sheet is not updated afterwards, we recommend `On Forwarding` for your Google Sheets integration if you want richer history and event context in the sheet.</Tip>

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# Jira
Source: https://docs.allquiet.app/integrations/outbound/jira

Connect Your Jira Boards with All Quiet to create Jira issues based on All Quiet incidents.

<Info>Setup time: 5 Min</Info>

Effortlessly connect Jira with All Quiet for streamlined incident management.

<Tip> The first part of this documentation focuses on creating the integration. The second explains how to create Jira issues based on All Quiet incidents (Outbound).
Want to create new incidents from Jira (Inbound)? Follow the [third part](/integrations/outbound/jira#create-all-quiet-incidents-from-jira) of this guideline. This way, you can seamlessly alert your development team about urgent Jira issues.</Tip>

## Create Outbound Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Jira".
2. Select a `Team`. <Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Select `Jira` as the integration's type.
4. Forwarding settings:
   1. **Default:** `Always After Forwarding` -  Jira issues will only be created if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Jira integration that automatically forward incidents in specific scenarios.
   2. **Alternative**: `Always` will automatically forward all incidents to Jira and create issues, unless excluded by additional [advanced routing rules](/advanced/routing).
      <Tip>You can change your selection anytime.</Tip>
5. Click `Create Outbound Integration`.

<img />

### Add All Quiet to your Jira Space

Once you've successfully created your new outbound integration, you'll automatically be redirected to its `Settings` page.

1. Observe that the installation status of the All Quiet integration is still pending.
2. To complete the integration with Jira, click `Add to Jira`.

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/jira#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

You'll be redirected to Jira, where you'll have to login first.

After login, you you’ll need to grant All Quiet permissions for your the Jira site.
We request only the permissions essential for All Quiet to operate correctly. These permissions are utilized solely when you interact with the app and are never used for any other purpose.

1. If your Atlassian account is linked to more than one Jira site, select the site you want to connect All Quiet to.
2. Click `Accept`.

<img />

## Configure Outbound Integration

Next, your are redirected back to your Jira integration's `Settings` page in All Quiet.
Now, you need to configure the integration.

1. As you can see, the Installation Status changed to `installed`.
2. Select the Jira Site you want to forward the All Quiet incidents to. You can only select sites your granted All Quiet permission to (see prior step).
3. Select the Jira project in which you want to create issues based on All Quiet incidents.
4. Select the `Issue Type for New Issues`. This defines the type of issue that is created from an All Quiet incident.
5. You can add a `Status for New Issues` created from All Quiet incidents. If you don't add a status, we use the default status from your Jira settings.

<img />

As you can manage the incident in both, All Quiet and Jira, you can sync the status between both projects. This allows you to manage the incident on one platform only and you don't have to make changes twice.

For changes in All Quiet:

1. Select the Jira issue status you want to set after resolving an incident in All Quiet.
2. Select the Jira issue status you want to set after re-opening an incident in All Quiet.

<img />

For changes in Jira:

1. Select the Jira status that sets an incident to `Resolved` in All Quiet.
2. Select the Jira status that sets an incident to `Reopened` in All Quiet.

Don't forget to **Save Jira Settings**.

<img />

<Check> If you decide to save & stop here, your Jira Outbound Integration with All Quiet is ready to go. Depending on your [setup](/integrations/outbound/jira#add-all-quiet-to-your-jira-space), All Quiet incidents will now automatically create issues in Jira or can be [forwarded manually](/essentials/incident#forwarding) to your Jira projects. The states will be synced based on your selection.</Check>

## Create All Quiet Incidents From Jira

This feature is basically the **Jira Inbound Integration**. You can create All Quiet incidents from Jira issues. Here's how it works:

<Tip>If you use both inbound and outbound, avoid creating multiple **Jira inbound** configurations that point to the same Jira site/project. Otherwise, an outbound-created issue can trigger another inbound configuration and accidentally create duplicate incidents or loops. We recommend using **only one inbound integration per Jira project**.</Tip>

<Note> **For Pro and Enterprise plan users:** No matter which teams you added in `Team Connections` when setting up the [outbound integration](/integrations/outbound/jira#add-all-quiet-to-your-jira-space), all All Quiet incidents will always be created in the integration's root team.</Note>

On your Jira Outbound integration’s details page in All Quiet, **scroll below section `Create Incidents From Jira`**

To create Incidents from Jira

1. Activate `Enable Incident Creation` and / or `Enable Incident Creation on Update`. **Otherwise**, Jira Issues will **not create** new All Quiet incidents **at all**.
   * `Enable Incident Creation`: All Quiet incidents will be created when **creating** a Jira issue matching the criteria below.
   * `Enable Incident Creation on Update`: All Quiet incidents will be created when **updating an existing** Jira issue to match the criteria below.
2. You can select if only Jira Issues that are created in a **certain status** will create an All Quiet incident. If omitted, incidents will be created no matter of the state.
   <Warning>For `Enable Incident Creation`: Keep in mind that when you create a new Jira issue, Jira automatically creates it in the default status of the workflow, even if you select another status during issue creation.</Warning>
3. You can select if only Jira Issues that are created with a **certain type** (Task, Bug...) will create an All Quiet incident. If omitted, incidents will be created no matter the issue type.
4. You can select if only Jira Issues that are created with a **certain priority** will create an All Quiet incident. If omitted, incidents will be created no matter the priority.
   1. `No Priority`, `Highest` & `High` will create All Quiet incidents with `Critical` severity
   2. `Medium` priority will create All Quiet incidents with `Warning` severity
   3. `Low` & `Lowest` priority will create All Quiet incidents with `Minor` severity
5. You can select if only Jira Issues that are created with **certain labels** will create an All Quiet incident. If omitted, incidents will be created no matter the label.
6. You can select if Jira Issues that are created in a **certain state will create resolved All Quiet incidents**. If omitted, incidents will be always be created in open state.
7. `Save Jira Settings`.

<img />

<Check>You have successfully created the **Jira Inbound Integration**. To manage your settings, open your Jira Outbound Integration details page.</Check>

To check if everything works as expected, create a Jira Issue that should create an All Quiet incident based on your integrations. Then, navigate to the incidents overview in All Quiet. You should find an incident created by Jira.

<img />

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# Linear
Source: https://docs.allquiet.app/integrations/outbound/linear

Connect Your Linear Teams with All Quiet to create Linear issues based on All Quiet incidents.

<Info>Setup time: 5 Min</Info>

Effortlessly connect Linear with All Quiet for streamlined incident management.

<Tip> The first part of this documentation focuses on creating the integration. The second explains how to create Linear issues based on All Quiet incidents (Outbound).
Want to create new incidents from Linear (Inbound)? Follow the [third part](/integrations/outbound/linear#create-all-quiet-incidents-from-linear) of this guideline. This way, you can seamlessly alert your development team about urgent Linear issues.</Tip>

## Create Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Linear".
2. Select a `Team`. <Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Select `Linear` as the integration's type.
4. Forwarding settings:
   1. **Default:** `Always After Forwarding` - Linear issues will only be created if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Linear integration that automatically forward incidents in specific scenarios.
   2. **Alternative**: `Always` will automatically forward all incidents to Linear and create issues, unless excluded by additional [advanced routing rules](/advanced/routing).
      <Tip>You can change your selection anytime.</Tip>
5. Click `Create Outbound Integration`.

<img />

### Add All Quiet to Your Linear Space

Once you've successfully created your new outbound integration, you'll automatically be redirected to its `Settings` page.

1. Observe that the installation status of the All Quiet integration is still pending.
2. To complete the integration with Linear, click `Add to Linear`.

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/linear#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

You'll be redirected to Linear, where you'll have to login first.

<img />

After login, you you’ll need to grant All Quiet permissions in your the Linear workspace.

We request only the permissions essential for All Quiet to operate correctly. These permissions are utilized solely when you interact with the app and are never used for any other purpose.

Click `Authorize All Quiet`.

<img />

## Configure Outbound Integration

Then, your are redirected back to your Linear integration's details page in All Quiet.
Next, you need to configure the integration.

1. As you can see, the Installation Status changed to `installed`.
2. Select the Linear Team you want to forward the All Quiet incidents to.
3. Optionally, you can add a project.
4. Sync All Quiet changes to Linear: Select the Linear issue state you want to set after resolving an incident in All Quiet.
5. Sync All Quiet changes to Linear: Select the Linear issue state you want to set after re-opening an incident in All Quiet.
6. Sync Linear changes to All Quiet: Select the Linear state that sets an incident to `Resolved` in All Quiet.
7. Sync Linear changes to All Quiet: Select the Linear state that sets an incident to `Reopened` in All Quiet.

<img />

1. Additionally, you can add a `State for New Linear Issues` created from All Quiet incidents. If you don't add a state, we use the default state from your Linear settings.
2. You may add your Linear `Issue Labels` if you want to organize your Linear issues by labels.
3. In the severity mapping block, choose the Linear `Priority` each All Quiet severity should get when the issue is created. Every severity is configurable, and the default value is shown as a hint next to the field.

   | All Quiet severity | Linear priority (default) |
   | ------------------ | ------------------------- |
   | Critical           | Urgent                    |
   | Warning            | Medium                    |
   | Minor              | Low                       |

<img />

<Check> If you decide to save & stop here, your Linear Outbound Integration with All Quiet is ready to go. Depending on your [setup](/integrations/outbound/linear#add-all-quiet-to-your-linear-space), All Quiet incidents will now automatically create issues in Linear or can be [forwarded manually](/essentials/incident#forwarding) to your Linear workspace. The states will be synced based on your selection.</Check>

## Create All Quiet Incidents From Linear

This feature is basically the **Linear Inbound Integration**. You can create All Quiet incidents from Linear issues. Here's how it works:

<Tip>If you use both inbound and outbound, avoid creating multiple **Linear inbound** integrations that point to the same Linear workspace/team. Otherwise, an outbound-created issue can trigger another inbound integration and accidentally create duplicate incidents or loops. We recommend using **only one inbound integration per Linear workspace/team**.</Tip>

<Note> **For Pro and Enterprise plan users:** No matter which teams you added in `Team Connections` when setting up the [outbound integration](/integrations/outbound/linear#add-all-quiet-to-your-linear-space), all All Quiet incidents will always be created in the integration's root team.</Note>

On your Linear Outbound integration’s details page in All Quiet, **scroll below section `Create Incidents From Linear`**

To create Incidents from Linear

1. Activate `Enable Incident Creation` and / or `Enable Incident Creation on Update`. **Otherwise**, Linear Issues will **not create** new All Quiet incidents **at all**.
   * `Enable Incident Creation`: All Quiet incidents will be created when **creating** a Linear issue matching the criteria below.
   * `Enable Incident Creation on Update`: All Quiet incidents will be created when **updating an existing** Linear issue to match the criteria below.
     <Warning>Please note that for **Incident Creation on Update**, Incident creation might take a while as Linear always waits to see if the actions performed on the issue are finished or if the user is still making adjustments, before sending updates (the incident) to us.</Warning>
2. You can select if only Linear Issues that are created in a **certain state** will create an All Quiet incident. If omitted, incidents will be created no matter of the state.
3. You can select if only Linear Issues that are created with **certain labels** will create an All Quiet incident. If omitted, incidents will be created no matter the label.
4. You can select if only Linear Issues that are created with a **certain priority** will create an All Quiet incident. If omitted, incidents will be created no matter the priority.

<img />

1. Additionally to filtering by priority, you can also map the Linear priorities to All Quiet severities. In the severity mapping block, choose which Linear priorities create which All Quiet severity. Each severity accepts multiple priorities, so you can group them as you like. The defaults are shown as hints next to the fields:

   | All Quiet severity | Linear priorities (default) |
   | ------------------ | --------------------------- |
   | Critical           | `No Priority`, `Urgent`     |
   | Warning            | `High`, `Medium`            |
   | Minor              | `Low`                       |

   <Note>If you change the mapping and a Linear issue arrives with a priority that triggers incident creation but is not assigned to any severity, the incident is created with `Critical` severity.</Note>
2. You can select if Linear Issues that are created in a **certain state will create resolved All Quiet incidents**. If omitted, incidents will be always be created in open state.

Save your settings.

<img />

<Check>You have successfully created the **Linear Inbound Integration**. To manage your settings, open your Linear Outbound Integration details page.</Check>

To check if everything works as expected, create a Linear Issue that should create an All Quiet incident based on your integrations. Then, navigate to the incidents overview in All Quiet. You should find an incident created by Linear.

<img />

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# Mattermost
Source: https://docs.allquiet.app/integrations/outbound/mattermost

Connect Your Mattermost Server with All Quiet to Manage Incidents from Mattermost

<Info>Setup time: 10 Min</Info>

Integrate your Mattermost Server with All Quiet for efficient incident management right from within Mattermost.

<Tip> The first part of this documentation focuses on creating the integration. The second explains how to send All Quiet incidents to your Mattermost channels (Outbound).
Want to create new incidents from your Mattermost channels (Inbound)? Follow the [third part](/integrations/outbound/mattermost#create-incidents-from-mattermost) of this guideline.</Tip>

## Create Outbound Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Mattermost".
2. Select a `Team`. <Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Select `Mattermost` as the integration's type.
4. Forwarding settings:
   1. **Default:** `Always` will automatically forward all incidents to your Mattermost Server, unless excluded by [advanced routing rules](/advanced/routing).
   2. **Alternative**: `Always After Forwarding` - Messages will only be sent if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) that automatically forward incidents in specific scenarios. After the initial Forwarding, all updates will automatically be sent.
      <Tip>You can change your selection anytime.</Tip>
5. Click `Create Outbound Integration`.

<img />

## Send All Quiet Incidents to Mattermost

Once you've successfully created your new outbound integration, you'll automatically be redirected to its `Settings` page.

1. Observe that the installation status is still pending.
2. To activate the outbound integration, enable the toggle `Send incidents to Mattermost` and follow the next steps in this guide.
3. To activate the inbound integratoin, enable the toggle `Create incidents from Mattermost` and follow [this part of the setup guide](/integrations/outbound/mattermost#create-incidents-from-mattermost).

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/mattermost#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

After enabling `Send incidents to Mattermost` to send All Quiet incidents to Mattermost, you add a bit more information.

1. Add the URL of your Mattermost server.
2. Click `Save`.

To activate the integration, we need to create a Bot on Mattermost in the next step and paste the Bot's access token into our integration settings in All Quiet.

<img />

In Mattermost

1. Open the menu in the top left corner.
2. In the menu, select `Integrations`.

<img />

Next, select `Bot Accounts` as integration type.

<img />

Click `Add Bot Account`.

<img />

1. Give your Bot a descriptive `Username`, like "all\_quiet".
2. You may want to add our Logo as `Bot Icon`.
3. Optionally, you can add a descriptive `Display Name` that adds more information than the `Username`, like "All Quiet Incidents" or "Incident from All Quiet".
4. "Member" `Role` is sufficient.
5. We recommend to enable `post:all` to enable the Bot to post into a maximum number of channels.
6. Finish the setup by clicking `Create Bot Account`.

<img />

Copy the genererated access `Token`. You will need it in the next step to activate the connection in All Quiet.

<img />

Back in your Mattermost Integration setting in All Quiet,

1. paste the `Token` into the `Bot Access Token` field.
2. `Save` your settings.

Now, before we can add the integration to your Mattermost channels, we need to add the Bot to your Mattermost team(s).

<img />

To add the Bot to your Mattermost teams, go back to Mattermost.

1. Open the menu in the top left corner.
2. In the menu, select `System Console`.

<img />

In the sidebar, select `User Management` > `Teams` (1).

<img />

Select the team you want to add the Bot to and click `Edit`.

<img />

On the `Team Configuration` page, scroll down to the `Members` section. Click `Add Members`.

<img />

1. Select the Bot from the list.
2. Click `Add`.

<img />

`Save` your team configuration with your newly added member.

<img />

Now, open the your Mattermost Integration settings in All Quiet.
<Tip> You might need to refresh the screen to see the new options </Tip>

1. As you can see, we successfully added the Bot to your Mattermost `Team` in the last step. Select the Mattermost Team you want to connect and send incidents to.
2. You can change your integration settings to “**Read Only**”. In this mode, we will not send any action buttons to Mattermost, meaning users cannot interact with the messages. This is ideal if you want to use the integration for internal stakeholder management.
3. Configure where All Quiet sends incident updates in the **Fixed Channels** and **Dynamic Channels** sections.

### Fixed Channels

Select the Mattermost `Channels` you want to send incidents to. You can decide to either:

* Send all incidents to the same channels.
* Route incidents to different channels based on incident severity.

<Note> You need to invite the Bot to the desired Mattermost channels first. After that, the channels will appear in All Quiet, and you can select them. This works for both public and private channels.</Note>

<img />

### Dynamic Channels

Instead of—or in addition to—Fixed Channels, you can create a **dedicated Mattermost channel per incident**. When an incident matches your configured severities, All Quiet creates a new channel, posts all incident updates there, and manages the channel lifecycle for you.

1. Enable **Dedicated channels per incident**.
2. Set a **channel name prefix**. Channel names are generated from the prefix, date, title slug, and short incident ID, then sanitized to fit Mattermost's naming limits.
3. Select the **severities** that should trigger a dedicated channel.
4. Choose whether new channels are **public** or **private**.
5. Optionally enable **Invite on-call members** to add currently on-call users to the channel when it is created.
6. Configure **archiving**:
   * **Auto-Archive on resolve or archive** — archive the channel when the incident is resolved or archived in All Quiet.
   * Optionally set an **archive delay** to wait before archiving (useful if you want a short grace period after resolution or need the channel for a post-mortem analysis).

<Note>If an incident is reopened, All Quiet unarchives the dedicated channel so updates continue there.</Note>

Save your integration `Settings`.

<img />

<Check>Your outbound integration is now fully set up. Now it's time to send incidents to your Mattermost channels.</Check>

### Engage with Incidents Directly in Mattermost

<Note> Only Teams that are connected with the integration in All Quiet will send their incidents to Mattermost. You can always change the current settings via the [`Team Connections` page](/integrations/outbound/mattermost#create-outbound-integration).</Note>

After finishing the setup, our integration sends an interactive message to your designated Mattermost channels. This allows you to manage incidents seamlessly, mirroring the experience on our iOS, Android, and Web Apps, all without leaving Mattermost.

<Info> If incident grouping is enabled, All Quiet will only include the <b>grouping attributes</b> in the Mattermost messages we send (the same fields used to group events into an incident). Learn more in our [Inbound Integrations docs](/essentials/inbound#optional-additional-attribute-keys).</Info>

<Info> For compliance reasons, only Users with rights in the All Quiet team(s) connected to the incident can interact with the Message. Additionally, if users create incidents manually they can alway interact with the specific incident no matter which team(s) are assigned.</Info>

<img />

<Check>Mattermost is now integrated with All Quiet, simplifying incident management by consolidating notifications and actions in one place.</Check>

## Create Incidents from Mattermost

You can create All Quiet incidents from Mattermost using custom slash commands.

To create `All Quiet incidents from Mattermost`,

1. enable the respective toggle in your Mattermost integration settings in All Quiet.
2. Note that we need to genererate a `Slash command secret token` and past it here. We will generate the token in the next steps.
3. Copy the `Slash command URL` by clicking on it. You will need it to connect the Mattermost slash command with All Quiet.

<img />

Back in Mattermost

1. Open the menu in the top left corner.
2. In the menu, select `Integrations`.

<img />

This time, select `Slash Commands` as integration type.

<img />

Click `Add Slash Command`.

<img />

1. Add a `Title` for the slash command, like `Create All Quiet Incident`.
2. You may add a `Description`.
3. Define the `Command Trigger Word`. Select something that is easy to remember and descriptive enough for you users to understand what the command does, e.g. `allquiet_incident`.
   <Tip> If you add more than one Mattermost integration to your All Quiet Organization, you will need to add different slash commands for each integration. Use descriptive commands, e.g. include the connected All Quiet Teams in the command.</Tip>
4. Paste in the `Request URL`. This is the `Slash command URL` you copied on All Quiet.
5. As request method, select `Post`.
6. We recommend activating `Autocomplete`. When activated, your users will see the full command after typing "/". You can even add `Autocomplete Hints`or `Autocomplete Descriptions` to clarify what the slash command does.
7. `Save` the slash command.

<img />

Copy the genererated `Token`. You will need it in the next step to connect the command with All Quiet.

<img />

Back in All Quiet,

1. paste the `Slash command secret token` into your Mattermost integration settings.
2. Save your settings.

<img />

<Check> Now, your users can create All Quiet incidents from your Mattermost channels. </Check>

Here's how it works:

1. Once typing "/" into the input field,
2. the autocomplete function shows the newly created slash command. Select it and click enter.

<img />

The command opens a pop-up window in which you can create the incident.

1. Choose the team you want to create the incident in.
   <Info> For compliance reasons, Users will only be able to select from the All Quiet teams they have roles in and that are connected to the Mattermost integration.</Info>
2. Select the severity of the incident.
3. Add the Incident Title.
4. Optional and recommended: Add a `Description` to give context.
5. Click `Creat Incident` to create the incident in All Quiet.

<img />

<Check> The incident is successfully created in the selected All Quiet team and triggers it's escalations. </Check>

<img />

## Hints and Troubleshooting

* **Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes.
* Deactivating the Toggles to `Send incidents to Mattermost` / `Create Incidents from Mattermost` does not delete saved settings or tokens but simply pauses outbound / inbound functionality.
* If you set up > 1 Mattermost outbound integration and two bots are in the channel, there will only be one incident message (sent by the first bot who was triggered) that users of both bots can interact with.


# Microsoft Teams
Source: https://docs.allquiet.app/integrations/outbound/microsoft-teams

Connect your MS Teams channels with All Quiet to manage incidents effortlessly, all within MS Teams.

<Info>Setup time: 3 Min</Info>

Seamlessly integrate your MS Teams channels with All Quiet to streamline incident management directly within MS Teams.

<Tip> The first part of this documentation focuses on creating the integration. The second explains how to send All Quiet incidents to your Microsoft Teams channels (Outbound).
Want to create new incidents from your Microsoft Teams channels (Inbound)? Follow the [third part](/integrations/outbound/microsoft-teams#create-new-all-quiet-incidents-directly-from-ms-teams) of this guideline.</Tip>

Unlike most of our integrations, this setup begins in your MS Teams channels instead of the All Quiet web app.

## Add All Quiet to your MS Teams Channels

If you are a `Team Member` in MS Teams, ensure you have the necessary permissions to add an app. If not, contact your MS Teams `Team Owner` or `IT Administrator` for assistance.

1. In the Microsoft Teams Application, click `Apps`.
2. In the Search Bar, enter `All Quiet`.
3. Select the `All Quiet` app (or, if you are a allquiet.eu user, the `All Quiet EU` app) from the search results and click `Add` or `Open` .

<img />

Next, click `Add` or `Open` in the Pop up.

By using All Quiet, you grant the necessary permissions for the All Quiet MS Teams app. We only request permissions essential for the app to function effectively.

<img />

1. Select the first MS Teams channel to integrate with All Quiet. Later, you can extend All Quiet to all channels within the same MS Team. If you’d like to use All Quiet with another MS Team, simply repeat this process and add it to a channel in that team.
2. Click `Go`.

<img />

You will be redirected to the selected MS Teams channel, where you’ll receive a message from the All Quiet app.
Click `Connect All Quiet` to link All Quiet with MS Teams. After that, you will be taken to your All Quiet Web App.

<Note>To establish the connection with All Quiet, you must log into your All Quiet account and be a member of at least one team in All Quiet.</Note>

<img />

### Set up MS Teams Integration in All Quiet

You will be redirected to a draft page for your MS Teams integration in All Quiet.

1. In the `Display Name` field, enter a name for your integration. For example, you can name it "MS Teams".
2. As `All Quiet Team`, select the All Quiet Team you want to connect with MS Teams. This will enable you to send incidents from this All Quiet Team to MS Teams and to create incidents in MS Teams to be sent back to this All Quiet team.
   <Note>**Standard plan users**: Later, you can connect additional All Quiet Teams using the ["Connect" command](/integrations/outbound/microsoft-teams#connect-additional-all-quiet-teams-with-ms-teams) in MS Teams. This will create an extra MS Teams integration for each All Quiet team.</Note>
   <Note>For **Organizations** with **Pro and Enterprise plan**: You will be able to add additional teams in the next step, allowing you to use the same MS Teams integration across several teams of your organization. This way, you can manage one incident across multiple teams, all from your MS Teams channels.</Note>
3. Click `Create & Connect` to connect All Quiet and MS Teams.

<img />

## Send Incidents From All Quiet to MS Teams

To send All Quiet incidents to your MS Teams channels, you must complete the following additional configuration steps.

1. Open the `Edit` tab of your Microsoft Teams integration on All Quiet
2. Select your preferred `Forwarding` settings:
   1. **Default:** `Always` will automatically forward all incidents to your Microsoft Teams Channels, unless excluded by [advanced routing rules](/advanced/routing).
   2. **Alternative**: `Always After Forwarding` - Messages will only be sent if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Microsoft Teams integration that automatically forward incidents in specific scenarios. After the initial Forwarding, all updates will automatically be sent.
      <Tip>You can change your selection anytime.</Tip>
3. Optionally enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.

Confirm by clicking `Save`.

<img />

Next, open the `Microsoft Teams Settings` tab. Here, you can configure additional information.

1. In the `Settings` subsection, you can see the connected MS Team.
   * **Read Only**: You can change your integration settings to “**Read Only**”. In this mode, we will not send any action buttons to your Microsoft Teams Channels, meaning users cannot interact with the messages. This is ideal if you want to use the integration for internal stakeholder management.
   * **Tag On-Call Members**: You can tag the on-call members in the related Microsoft Teams channels when an an incident is assigned to them.
2. Configure where All Quiet sends incident updates in the **[Fixed Channels](/integrations/outbound/microsoft-teams#fixed-channels)** and
3. **[Dynamic Channels](/integrations/outbound/microsoft-teams#dynamic-channels)** sections.

<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

### Fixed Channels

Select the MS Teams channels where you want to send All Quiet incidents to. You can choose from every channel in the connected MS Team(s). <Note>Regardless of its name in MS Teams, your first connected MS Teams channel will always be referred to as `General` in All Quiet. Unfortunately, this is beyond our control.</Note>

<img />

### Dynamic Channels

Instead of—or in addition to—Fixed Channels, you can create a **dedicated MS Teams channel per incident**. When an incident matches your configured severities, All Quiet creates a new channel, posts all incident updates there, and manages the channel lifecycle for you.

1. Enable **Dedicated channels per incident**.
2. Set a **channel name prefix**. Channel names are generated from the prefix, date, title slug, and short incident ID, then sanitized to fit Microsoft Teams' naming limits.
3. Select the **severities** that should trigger a dedicated channel.
4. **Disable on-call invite**: You can disable the automatic invitation of the on-call members to the dedicated channel when an incident is assigned to them.
   <Warning> Microsoft Teams cannot automatically add the dedicated channel to the overview channels. We heavily recommend activating the [**tag on-call members**](/integrations/outbound/microsoft-teams#send-incidents-from-all-quiet-to-ms-teams) option and / or leave the **on-call invite** enabled to increase the visibility of the dedicated channel for the on-call members.</Warning>
5. Configure **archiving**:
   * **Auto-Archive on resolve or archive** — archive the channel when the incident is resolved or archived in All Quiet.
   * Optionally set an **archive delay** to wait before archiving (useful if you want a short grace period after resolution).

Save your settings.

<Note>If an incident is reopened, All Quiet unarchives the dedicated channel so updates continue there.</Note>

<img />

Here’s an example of how an All Quiet incident will appear in MS Teams. You can manage your entire incident from within MS Teams, including your [status pages](/advanced/status-pages), and [forward](/essentials/incident#forwarding) the incident to other integrations for ticketing or post-mortems.

<Info> If incident grouping is enabled, All Quiet will only include the <b>grouping attributes</b> in the Microsoft Teams messages we send (the same fields used to group events into an incident). Learn more in our [Inbound Integrations docs](/essentials/inbound#optional-additional-attribute-keys).</Info>

<Info> For compliance reasons, only Users with rights in the All Quiet team(s) connected to the incident can interact with the Message.</Info>

<img />

<Check>You can now use MS Teams as an outbound integration to send All Quiet incidents to your team channels. Below, you’ll find instructions on how to use MS Teams to create new incidents as well.</Check>

## Create New All Quiet Incidents Directly From MS Teams

To create a new incident in All Quiet from your MS Teams channel, start a new post in a channel you have added to your [Fixed Microsoft Teams channels](/integrations/outbound/microsoft-teams#fixed-channels) and type `@All Quiet`. You can use the Tab key for autocomplete.

<img />

Next, you will receive command suggestions.

1. Select the command `incident` by either clicking on it or typing it.
2. Click `Post` to create the incident form.

<img />

Fill out the form in order to create an incident.

1. You will see the command that triggered the form.
2. Enter a `Title` for the incident.
3. Enter a `Description`.
4. Select the `Severity`.
5. Select the All Quiet Team where you want to create the incident. If the right team is not listed, you will need to add it first. See [below](/integrations/outbound/microsoft-teams#connect-additional-all-quiet-teams-with-ms-teams) for more. <Info> For compliance reasons, Users will only be able to select from the All Quiet teams they have rights in & that are connected to Microsoft Teams via the integration.</Info>
6. Click `Create Incident` to submit.

<img />

This is how the new incident will appear in MS Teams...

<img />

...and this is how it will look in the incident overview on the All Quiet web app.

<img />

## Connect Additional All Quiet Teams With MS Teams

<Note>With the following command, you will eventually create an additional MS Teams integration for each team in All Quiet. **We recommend Pro and Enterprise users** to add the integration to further All Quiet teams via the [integration's setup page in All Quiet](/integrations/outbound/microsoft-teams#send-incidents-from-all-quiet-to-ms-teams) in case they want to share incidents across several teams. </Note>

To connect another All Quiet team with MS Teams, simply go to your teams channel and enter `@All Quiet` followed the command `connect`.

<img />

This will trigger another `Connect` message. By clicking `Connect more All Quiet teams`, you will be redirected to your All Quiet web app with a drafted MS Teams integration. Simply follow the steps from [above](/integrations/outbound/microsoft-teams#set-up-ms-teams-integration-in-all-quiet) and select the additional All Quiet team wish to connect.

<img />

## Disconnect All Quiet and MS Teams

**To disconnect** your Microsoft Team from All Quiet, enter the command `@All Quiet disconnect` and confirm by clicking on `Disconnect Now` in the interactive message the bot is sending you afterwards.

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.

### On-call tagging or dedicated channels not working

<span />

If you connected Microsoft Teams **before August 10, 2026**, [**Tag On-Call Members**](/integrations/outbound/microsoft-teams#send-incidents-from-all-quiet-to-ms-teams) and [**Dedicated channels per incident**](/integrations/outbound/microsoft-teams#dynamic-channels) may not work—the All Quiet app is likely missing updated Microsoft Graph permissions in your tenant. These features (on-call tagging, notifying on-call members about dedicated channels, and auto-archiving dedicated channels) were added on that date. Integrations connected on or after that date receive the permissions during setup.

These permissions apply **only** to those optional features—not to basic incident forwarding.

Ask a Microsoft 365 admin to grant **admin consent** for these **application** permissions on the All Quiet app:

| Permission                      | Description                                                          |
| ------------------------------- | -------------------------------------------------------------------- |
| `Channel.Create`                | Create channels                                                      |
| `ChannelSettings.ReadWrite.All` | Read and write the names, descriptions, and settings of all channels |
| `TeamMember.Read.All`           | Read the members of all teams                                        |
| `TeamsActivity.Send`            | Send a teamwork activity to any user                                 |

**How to grant them:** Have a Microsoft 365 admin open the All Quiet app in **Microsoft Teams admin** or **Entra ID (Azure AD) → Enterprise applications** and approve the permissions above, **or** remove and re-add the All Quiet bot/app to your team so the updated consent prompt appears—then admin-consent the permissions.


# Notion
Source: https://docs.allquiet.app/integrations/outbound/notion

Connect your Notion Workspace with All Quiet to effortlessly prepare documentations or retrospectives on incidents.

<Info>Setup time: 2 Min</Info>

Connect Notion with All Quiet for streamlined post-incident analysis.

## Create Outbound Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Notion".
2. Select a `Team`. <Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Select `Notion` as the integration's type.
4. Forwarding settings:
   1. **Default:** `On Forwarding` - Notion Pages will only be created if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Confluence integration that automatically forward incidents in specific scenarios.
   2. **Alternative**: `On Incident Creation` will automatically forward all incidents to Notion as soon as they are created and create new Notion Pages.
      <Tip>You can change your selection anytime, but we recommend to select `On Forwarding`. We will explain why in the [example](/integrations/outbound/notion#creating-an-incident-retro-page-in-notion) below.</Tip>
5. Click `Create Outbound Integration`.

<img />

### Add All Quiet to your Notion Workspace

Once you've successfully created your new outbound integration, you'll automatically be redirected to its `Settings` page.

1. Observe that the installation status of the All Quiet integration is still pending.
2. To complete the integration with your Confluence site, click `Add to Notion`.

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/notion#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

You'll be redirected to Notion, where you'll have to login first.

After login, you you’ll need to select the parts of your Notion Workspace that you want to grant All Quiet permissions to.
We request only the permissions essential for All Quiet to operate correctly. These permissions are utilized solely when you interact with the app and are never used for any other purpose.

1. Click `Select pages`

<img />

1. Select the pages you want to give All Quiet access to. Note that you can only use these pages as parents for your All Quiet incidents. You can change the selection in your team's Notion Workspace under `Settings` > `My Connections`, anytime.
2. Click `Allow Access`.

<img />

Next, your are redirected back to your Notion integration's details page in All Quiet.
It's time to configure the integration.

As you can see, the Installation Status changed to `installed`.

1. Select the `Parent Pages` under which you want to create the pages for your All Quiet incidents. You can only select those Notion pages that you granted All Quiet permission to (see prior step).
2. Make sure to `Save Notion Settings` after select a parent page, otherwise you cannot forward any incidents.

<img />

<Check> Notion is now integrated with All Quiet. Depending on your [setup](/integrations/outbound/notion#add-all-quiet-to-your-notion-workspace), All Quiet incidents can now be [forwarded manually](/essentials/incident#forwarding) to your Notion Workspace or automatically create pages.</Check>

### Creating an Incident Retro Page in Notion

In the following part, we want to quickly demonstrate how a Notion page created from an incident can look like.

In the screenshot below, you can find an All Quiet incident.

1. There was some communication going on, and the team agreed to have a Retro for this incident. That's why Mads forwarded it to Notion.
2. The Notion page is linked.

<img />

Following the Link to Notion, you will see this:

1. As defined in my [integration's settings](/integrations/outbound/notion#add-all-quiet-to-your-notion-workspace), the page got created below `Parent Page` "All Quiet CI Integration Tests"
2. The title of the Notion page is a combination of the timestamp of the incident's creation and the incident title in All Quiet. Please note that timestamps in the title will always be based on your team's timezone.
3. In this section, you will find the main incident details, as well as a link to the incident in All Quiet (see section headline).
4. This part features all additional incident attributes you previously defined in our [mapping engine](/essentials/inbound#mapping-payloads). Moreover, if there are further links related to the incident, they will be listed here.
5. All events linked to the incident. Basically the communication in All Quiet.
6. The team members that were on-call during each event. Only Tier 1 members and members from higher Tiers that got notified due to escalations are listed.
   <Tip>As the Notion page is a snapshot of the All Quiet incident, we recommend to activate the [Trigger On Forwarding](/integrations/outbound/notion#add-all-quiet-to-your-notion-workspace) feature for your Notion integration. That is because when deciding to automatically create the page with incident creation, there won't be a lot history / events available.</Tip>

<img />

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# Salesforce
Source: https://docs.allquiet.app/integrations/outbound/salesforce

Connect Your Salesforce Org with All Quiet to create Salesforce cases based on All Quiet incidents.

<Info>Setup time: 5 Min</Info>

Effortlessly connect Salesforce with All Quiet for streamlined incident management.

<Tip> The first part of this documentation focuses on creating the integration. The second explains how to create Salesforce cases based on All Quiet incidents (Outbound).
Want to create new incidents from Salesforce (Inbound)? Follow the [third part](/integrations/outbound/salesforce#create-all-quiet-incidents-from-salesforce) of this guideline. This way, you can seamlessly alert your development team about urgent Salesforce cases.</Tip>

## Create Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Salesforce".
2. Select a `Root Team`. <Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Select `Salesforce` as the integration's type.
4. Forwarding settings:
   1. **Default:** `Always After Forwarding` - Salesforce cases will only be created if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Salesforce integration that automatically forward incidents in specific scenarios.
   2. **Alternative**: `Always` will automatically forward all incidents to Salesforce and create cases, unless excluded by additional [advanced routing rules](/advanced/routing).
      <Tip>You can change your selection anytime.</Tip>
5. Click `Create Outbound Integration`.

<img />

### Add All Quiet to Your Salesforce Org

Once you've successfully created your new outbound integration, you'll automatically be redirected to its `Settings` page.

Observe that the installation status of the All Quiet integration is still pending.
To complete the integration with Salesforce, we first need to install the All Quiet package in your Salesforce org. Click **`Install All Quiet package`.**

<img />

You will be redirected to Salesforce, where you'll have to login first.
Next, yu need to install the All Quiet package.

Select `Install for All Users` and `Click Install`.

<Note>   If you don't have the necessary permissions, reach ouut to one of your salesforce admins</Note>

<img />

In the popup, you need to confirm the installation and approve third party permissions for All Quiet (allquiet.app or allquiet.eu, based on your All Quiet URL).

<img />

After seeing that the installations was successful, navigate back to the All Quiet integration > `Salesforce settings` page in All Quiet.

Now, it's time to connect All Quiet to your Salesforce org. In this step, we'll verify the previous package installation.

Click `Add to Salesforce` to continue.

<img />

You're forwarded to Salesforce. If logged in, you see the following screen. Click `Allow` to connect All Quiet and Salesforce and to grant All Quiet the necessary permissions to your Salesforce org.

<img />

## Configure Outbound Integration

You're forwarded to All Quiet, again. You should see that the connection was successful. This means that the package was installed, that the necessary permissions were granted and that the webhook configuration was created (the webhoook is generated automatically).

<Note> Multiple installations are possible. You can add multiple All Quiet integrations to your Salesforce org. However, they all share the same webhook configuration. This means that all All Quiet incidents will be created in the same Salesforce queue.</Note>
<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/salesforce#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

Now that the connection was successful, you can configure the integration.

1. You can select the record type new Salesforce cases should be created with from All Quiet incidents.
2. **Assignees stay in sync** between All Quiet incidents and Salesforce cases by matching **email address**. When an incident is assigned in All Quiet, All Quiet looks up the Salesforce user with the same email and sets them as the case assignee (and the other way around when the case assignee changes in Salesforce). If no matching assignee or creator is found in Salesforce, you can select a fallback via the `Case queue` field.

<img />

You can select how **All Quiet incident states** should be synced **to Salesforce** cases.

1. `Initial case status`: Select the Salesforce case status you want to set for new cases created from All Quiet incidents.
2. `Case priority`: The priority a new Salesforce case is created with. If left empty, Salesforce uses the default priority of the selected record type’s support process.
3. Add a `Case origin`: Select the Salesforce case origin you want to set for new cases created from All Quiet incidents.
4. Select if the `Case Status` should be updated if an `All Quiet` incident is resolved. Per default, we don't update the case status if an incident is resolved.
5. Select if the `Case Status` should be updated if an `All Quiet` incident is reopened. Per default, we don't update the case status if an incident is reopened.

<img />

You can select how **Salesforce case states** should be synced **to All Quiet** incidents.

1. `Case statuses that resolve an incident`: Select the Salesforce case statuses that should resolve an incident in All Quiet.
2. `Case statuses that reopen an incident`: Select the Salesforce case statuses that should reopen an incident in All Quiet.
3. `When Salesforce case is deleted`: Select what should happen to an All Quiet incident if the Salesforce case is deleted.

<img />

<Check> If you decide to save & stop here, your Salesforce Outbound Integration with All Quiet is ready to go. Depending on your [setup](/integrations/outbound/salesforce#add-all-quiet-to-your-salesforce-org), All Quiet incidents will now automatically create cases in Salesforce or can be [forwarded manually](/essentials/incident#forwarding) to your Salesforce org. The statuses will be synced based on your selection.</Check>

## Create All Quiet Incidents From Salesforce

This feature is basically the **Salesforce Inbound Integration**. You can create All Quiet incidents from Salesforce cases. Here's how it works:

<Tip>If you use both inbound and outbound, avoid creating multiple **Salesforce inbound** integrations that point to the same Salesforce org/queue. Otherwise, an outbound-created case can trigger another inbound integration and accidentally create duplicate incidents or loops. We recommend using **only one inbound integration per Salesforce org/queue**.</Tip>

<Note> **For Pro and Enterprise plan users:** No matter which teams you added in `Team Connections` when setting up the [outbound integration](/integrations/outbound/salesforce#add-all-quiet-to-your-salesforce-org), all All Quiet incidents will always be created in the integration's root team.</Note>

On your Salesforce Outbound integration's details page in All Quiet, **scroll below section `Create Incidents From Salesforce`**

To create Incidents from Salesforce activate `Enable Incident Creation` and / or `Enable Incident Creation on Update`. **Otherwise**, Salesforce Cases will **not create** new All Quiet incidents **at all**.

1. `Enable on new case`: All Quiet incidents will be created when **creating** a Salesforce case matching the criteria below.
2. `Enable on case update`: All Quiet incidents will be created when **updating an existing** Salesforce case to match the criteria below.
3. You can select if only Salesforce Cases that are created in / updated to a **certain status** will **create an All Quiet incident**. If omitted, incidents will be created no matter of the status.
4. You can select if Salesforce Cases that are created with / updated to a **certain status** will create **resolved All Quiet incidents**. If omitted, incidents will always be created in `Open` state.
5. You can select if only Salesforce Cases that are created with / updated to a **certain priority** will create an All Quiet incident. If omitted, incidents will be created no matter the priority.
6. Optionally you can only create incidents for cases that have a certain `record type`. If omitted, incidents will be created for all record types.
7. Make sure to `Save` your settings.

<img />

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# ServiceNow
Source: https://docs.allquiet.app/integrations/outbound/servicenow

Create and update ServiceNow incidents from All Quiet incidents.

<Info>Setup time: 5 Min</Info>

The **ServiceNow Outbound** integration connects All Quiet to your ServiceNow instance so incidents in All Quiet **create** and **update** corresponding ServiceNow incidents.

<Tip>
  Pair this with the [ServiceNow Inbound integration](/integrations/inbound/servicenow) if you want ServiceNow and All Quiet to stay aligned when both systems change. Inbound sends ServiceNow-driven open and resolved behavior into All Quiet; outbound pushes All Quiet changes into ServiceNow.
</Tip>

## What this integration does

* Creates ServiceNow incidents when All Quiet incidents are forwarded according to your settings.
* Updates the linked ServiceNow incident as the All Quiet incident changes.
* Applies to incidents from **any** source: observability, email, webhook, or ServiceNow via the inbound integration. The outbound integration operates on All Quiet incidents as configured. It does not require the incident to have originated in ServiceNow.

## Create ServiceNow Outbound integration

1. Open the `Outbound Integrations` tab.
2. Click `+ Create`.

<img />

1. Enter a **Display Name** (for example `ServiceNow`).
2. Select a **Root Team**. <Note>For organizations on Pro or Enterprise, you can add further team connections where your plan allows.</Note>
3. Choose **ServiceNow** as the integration type.
4. **Forwarding** settings (same idea as other outbound integrations):
   * **Default:** `Always After Forwarding` — ServiceNow incidents are created when users [manually forward](/essentials/incident#forwarding) incidents or when [advanced routing](/advanced/routing) forwards them automatically.
   * **Alternative 1:** `Always` — forward all incidents to ServiceNow unless excluded by routing rules.
   * **Alternative 2:** `Only On Forwarding` — forward a snapshot of the current incident history to ServiceNow in the moment users [manually forward](/essentials/incident#forwarding) or if you set up [advanced routing](/advanced/routing) for your ServiceNow Outbound integration that automatically forwards incidents in specific scenarios. We will **not send** any incident **updates** to ServiceNow **afterwards**.
     <Tip>You can change forwarding behavior later in the integration settings.</Tip>
     5Í. Click `Create Outbound Integration`.

<img />

After creation, the integration's **ServiceNow Settings** page will open. Here you can configure the mapping of All Quiet fields to ServiceNow fields. But in the first step, you will need to add your ServiceNow instance URL and authentication details.

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/servicenow#create-servicenow-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>

## Step 2 — Add your ServiceNow instance URL and authentication details

**Goal:** All Quiet uses **Basic authentication** (username + password) to call the ServiceNow **Table API** (`/api/now/table/...`): read and write rows on your table (default **`incident`**), and optionally read **`sys_choice`** so the All Quiet UI can load dropdown values for state, close code, and severity fields.

### Create the All Quiet user in ServiceNow

1. In ServiceNow, use the filter navigator (usually top left). Type **users**, then open **User Administration** → **Users**.
2. Click **New**.
3. Fill **User ID** (this is the **username** you'll later enter in your All Quiet **ServiceNow Outbound** integration), **Name**, and set a **Password** if the instance uses local authentication — or follow your organization’s SSO and password policy.
4. **Save** the user.
5. Open the **Roles** tab (or the Roles related list) and assign roles — see [Roles](#roles) below.

<Note>Optional: if your organization uses **Web service access only** for integration accounts, configure that according to your policy (not always required).</Note>

#### What access the integration needs

| Need                                                                                         | Why                                                                                                                                                                                                    |
| -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Read + write** on the incident table (or whichever **Table name** you configured) via REST | Create incidents from All Quiet (forward path) and **PATCH** state, close fields, and severity on updates.                                                                                             |
| **Read** on **`sys_choice`**                                                                 | Lets All Quiet load ServiceNow choice lists in the integration form. If this is denied, the UI can still work with manual values; you may see a warning about `sys_choice` or HTTP **403** in the app. |

#### Roles

**Minimum for a real instance:** A **custom role** (or clone of a small role) whose ACLs allow Table API read/write on **incident** (and your configured table) and read on **`sys_choice`** — exact names depend on your instance; your ServiceNow admin should confirm.

**Common “it works” combo on many instances** (still confirm with your admin): **`itil`** — typically covers incident operations used by agents and is often enough for Table API on **incident** if REST access is not blocked by other policies.

If choice lists fail with **HTTP 403** on **`sys_choice`**: an admin must grant **read** on **`sys_choice`** (direct ACL or an additional role that includes that read). Roles that include broader dictionary or choice access **vary by instance** — do not assume a second generic role name; use ACLs or admin guidance.

### After creating the user — connect from All Quiet

1. In All Quiet, open the team’s **ServiceNow** outbound integration → **ServiceNow Settings** → **Authorization** (or equivalent settings for instance credentials).
2. Enter **Instance URL** (for example `https://your-instance.service-now.com`), **Username** (the **User ID** you created in ServiceNow), **Password**, and **Table name** (default **`incident`**).
3. Click **Save** and **Test Connection**.

<img />

If the test passes but choice lists do not load, check the in-app message about **`sys_choice`** and adjust ServiceNow read access as described above.

## Configure updates and sync

On the integration’s **ServiceNow Settings**, configure how All Quiet maps to your ServiceNow table for **create** and **update**. Defaults assume the **`incident`** table and standard field names; change them if your instance differs.

When you also use [ServiceNow Inbound](/integrations/inbound/servicenow), align these rules with your inbound flow so you do not create conflicting loops — the product settings define which system wins for each transition.

### State Mapping

Mapping applies to the **`state`** field by default.

**State when Open in All Quiet**\
Internal ServiceNow value for the **state** field when the incident is **open** in All Quiet. When All Quiet can read ServiceNow **`sys_choice`**, pick from the list; otherwise enter the value your instance uses (often **numeric**).

**State when Resolved in All Quiet**\
Internal ServiceNow value for the **state** field when the incident is **resolved** in All Quiet. Same as above: use the dropdown when **`sys_choice`** is available, or type the internal ServiceNow value your instance expects.

<img />

### Resolving Mapping

ServiceNow usually requires additional information when resolving an incident. We will send these values to ServiceNow when you resolve an incident in All Quiet.

**Close code field name**\
On **incident**, this is usually **`close_code`**. Change it if your table uses another field for the resolution reason. The standard is **`close_code`**.

**Close notes field name**\
On **incident**, this is usually **`close_notes`**. Many ServiceNow data policies require **close notes** when resolving. The standard is **`close_notes`**.

**Close code when Resolved in All Quiet**\
Resolution reason sent when resolving (for example **`incident.close_code`**). **Required.** When **`sys_choice`** is readable, pick from the list; otherwise enter the internal choice value.

**Close notes when Resolved in All Quiet**\
Fallback text for the close-notes field when resolving (for example **`incident.close_notes`**) if the resolve action in All Quiet has **no** comment. If the user enters a comment while resolving, **that** text is sent instead. A typical default is **`Resolved from All Quiet`**.

<img />

### Severity mapping

All Quiet uses a **primary + optional secondary** field model for severity:

1. **Primary field** — The main ServiceNow field we update from All Quiet severity. Default API name: **`urgency`**. Change it if your process uses another primary field.
2. **Secondary field (optional)** — Enable with a toggle in the UI (for example **`impact`**). When enabled, we write **both** the primary and secondary fields **on create** and whenever **severity changes** in All Quiet.

If you set `urgency` and `impact` as primary and secondary fields, it lets ServiceNow **derive `priority` from its urgency / impact matrix** instead of writing **`priority`** directly, which matches how many instances calculate incident priority.

<Note>If the secondary field is off, only the primary field is updated. Choice lists for each field still come from **`sys_choice`** when your integration user can read them; otherwise enter internal values per field.</Note>

**Default mapping (primary field, typical `urgency`)**

Internal values we send for each All Quiet severity to the **primary** field by default. When you enable a **secondary** field, configure its mappings in the UI as well (your instance’s valid values for that field may differ from **`urgency`**).

| All Quiet | ServiceNow primary field (typical internal value) |
| --------- | ------------------------------------------------- |
| Critical  | `1`                                               |
| Warning   | `2`                                               |
| Minor     | `3`                                               |

<img />

<Check> ServiceNow is now integrated with All Quiet. Depending on your setup, All Quiet incidents can now be [forwarded manually](/essentials/incident#forwarding) to your ServiceNow Instance or automatically create incidents in ServiceNow.</Check>

## ServiceNow API Debugging

If you encounter issues with the integration, you can debug the API calls by looking at the bottom of your `ServiceNow Settings` tab in All Quiet. You will find the API calls and their responses there.

This view is **separate** from the integration **[History](/essentials/outbound#outbound-history)** tab, which records general outbound integration activity across all operations (same as other outbound integrations).

<img />

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. This is separate from **[ServiceNow API Debugging](#servicenow-api-debugging)** on the integration settings tab. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.

## Related

* [ServiceNow Inbound](/integrations/inbound/servicenow) — open and resolve All Quiet incidents from ServiceNow
* [Outbound Integrations](/essentials/outbound) — forwarding modes and concepts
* [Advanced routing](/advanced/routing) — control which incidents reach ServiceNow


# Slack
Source: https://docs.allquiet.app/integrations/outbound/slack

Connect Your Slack Workspace with All Quiet to Manage Incidents from Slack

<Info>Setup time: 3 Min</Info>

Integrate your Slack Workspace with All Quiet for efficient incident management right within Slack.

<Tip> The first part of this documentation focuses on creating the integration. The second explains how to send All Quiet incidents to your Slack channels (Outbound).
Want to create new incidents from your Slack channels (Inbound)? Follow the [third part](/integrations/outbound/slack#all-quiet-app-for-slack-commands) of this guideline.</Tip>

## Create Outbound Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Slack".
2. Select a `Team`. <Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Select `Slack` as the integration's type.
4. Forwarding settings:
   1. **Default:** `Always` will automatically forward all incidents to your Slack Workspace, unless excluded by [advanced routing rules](/advanced/routing).
   2. **Alternative**: `Always After Forwarding` - Messages will only be sent if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your All Quiet app for Slack that automatically forward incidents in specific scenarios. After the initial Forwarding, all updates will automatically be sent.
      <Tip>You can change your selection anytime.</Tip>
5. Click `Create Outbound Integration`.

<img />

## Add All Quiet App For Slack to Your Workspace

Once you've successfully created your new outbound integration, you'll automatically be redirected to its `Settings` page.

1. Observe that the installation status of the All Quiet app for Slack is still pending.
2. To complete the integration with your Slack Workspace, click `Add to Slack`.

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/slack#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan** - Manage your `Team Connections`: The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an Administrator in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

You are redirected to Slack where you'll be asked to grant permissions for the `All Quiet` App for Slack (or, if you are a allquiet.eu user, the `All Quiet EU` App for Slack).
We request only those permissions that are strictly necessary for All Quiet to function properly. We access this data solely when you interact with the app and never use it for any other purpose.
Click on `Allow`. To learn more about the data we collect, check out our [privacy policy](https://allquiet.app/privacy).

<img />

After you've granted All Quiet access to Slack, you'll be redirected back to All Quiet. Open the `Slack Settings` tab.

1. Observe that the Installation Status now indicates "installed".
2. You may now add the All Quiet for Slack app to your [Fixed Slack channels](/integrations/outbound/slack#fixed-channels) to forward incidents to or [create incidents from](/integrations/outbound/slack#all-quiet-app-for-slack-commands) Slack.
3. Additionally, you can create [Dynamic Slack channels](/integrations/outbound/slack#dynamic-channels) for each matching incident.

<img />

### Fixed Channels

Navigate to the desired channel in Slack where you want All Quiet to send incidents to.

1. Start by typing *`/invite @All Quiet`.* / *`/invite @All Quiet EU`.*
2. Select `All Quiet` (or, if you are a allquiet.eu user, the `All Quiet EU`) and then press `Enter` to add the app into your channel.

<img />

<img />

Back to your integration on All Quiet

From the channels you added the bot to, select those you want to send incidents to. You can decide to either:

* Send all incidents to the same channels.
* Route incidents to different channels based on incident severity.

<img />

### Dynamic Channels

<Warning>This feature is soon to come.</Warning>

Instead of—or in addition to—Fixed Channels, you can create a **dedicated Slack channel per incident**. When an incident matches your configured severities, All Quiet creates a new channel, posts all incident updates there, and manages the channel lifecycle for you.

1. Enable **Dedicated channels per incident**.
2. Set a **channel name prefix**. Channel names are generated from the prefix, date, title slug, and short incident ID, then sanitized to fit Slack's naming limits.
3. Select the **severities** that should trigger a dedicated channel.
4. Choose whether new channels are **public** or **private**.
5. Optionally enable **Invite on-call members** to add currently on-call users to the channel when it is created.
6. Configure **archiving**:
   * Auto-archive the channel when the incident is resolved or archived in All Quiet.
   * Optionally set an **archive delay** to wait before archiving (useful if you want a short grace period after resolution or need the channel for a post-mortem analysis).

<Note>If an incident is reopened, All Quiet creates a new the dedicated channel that is named like the original channel but with a suffix like \_-2. Updates will continue in the new channel.</Note>

<img />

### General Settings

1. You can change your integration settings to “**Read Only**”. In this mode, we will not send any action buttons to Slack, meaning users cannot interact with the messages. This is ideal if you want to use the integration for internal stakeholder management.
2. `Hide Activity History`: When enabled, the event history section is hidden from Slack incident messages.
3. There's an option to tag you on-call members in the related Slack channels when an an incident is assigned to them.
4. As soon as you added All Quiet to at least one [Fixed Slack channel](/integrations/outbound/slack#fixed-channels), you can set up an automated message you can use to inform your Slack channels who's currently on-call in the All Quiet team(s) connected to the integration.

To save, click `Save Slack Settings`.

<img />

### Engage with Incidents Directly in Slack

Each time you engage with incidents via All Quiet, our integration for Slack sends an interactive message to your designated channels. This allows you to manage incidents seamlessly, mirroring the experience on our iOS, Android, and Web Apps, all without leaving Slack.

<Info> If incident grouping is enabled, All Quiet will only include the <b>grouping attributes</b> in the Slack messages we send (the same fields used to group events into an incident). Learn more in our [Inbound Integrations docs](/essentials/inbound#optional-additional-attribute-keys).</Info>

<Info> For compliance reasons, only Users with rights in the All Quiet team(s) connected to the incident can interact with the Message. Additionally, if users create incidents manually they can alway interact with the specific incident no matter which team(s) are assigned.</Info>

<img />

<Check>Slack is now integrated with All Quiet, simplifying incident management by consolidating notifications and actions in one place.</Check>

## All Quiet App for Slack Commands

Now that All Quiet is installed on your Slack workspace you can use some handy commands. To see all available All Quiet for App Slack commands start by typing `/aq` and a window with available commands should appear.

<img />

### /aq oncall

Type in `/aq oncall` to directly see on Slack who is currently on-call in which escalation tier in all of your teams.

```
/aq oncall
```

<img />

<Tip> With `/aq oncall --ephemeral`, you can also see who's on-call, but this message is only visible for yourself. Nice hack if you don't want to spam your channel.</Tip>

### /aq new

Type in `/aq new` to trigger an All Quiet incident directly from Slack

```
/aq new
```

You can

* choose the team you want to create the incident in
  <Info> For compliance reasons, Users will only be able to select from the All Quiet teams they have rights in.</Info>
* the severity of the incident
* write a title for the incident
* add a description to the incident

<img />

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# Webhook
Source: https://docs.allquiet.app/integrations/outbound/webhook

Connect Any Third-Party Platform with All Quiet via `HTTP calls`

<Info>Setup time: 6 Min</Info>

Maximize your team's efficiency with All Quiet's outbound webhooks. Connect seamlessly with third-party platforms, enabling real-time alerts and maintaining operational awareness.

## Create Outbound Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Outbound Webhook".
2. Select a `Team`. <Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Select `Webhook` as the integration's type.
4. Forwarding settings:
   1. **Default:** `Always` will automatically forward all incidents to your Webhook, unless excluded by [advanced routing rules](/advanced/routing).
   2. **Alternative 1**: `Always After Forwarding` will only sent requests if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Webhook Outbound integration that automatically forward incidents in specific scenarios. **After Forwarding, all updates** of the incident **will also be pushed to the Outbound Webhook**.
   3. **Alternative 2**: `Only On Forwarding` will only forward a snapshot of the current incident history to your Outbound Webhook in the moment users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Webhook Outbound integration that automatically forwards incidents in specific scenarios. We will **not send** any incident **updates** to the Outbound Webhook **afterwards**.
      <Tip>You can change your selection anytime.</Tip>
5. Click `Create Outbound Integration`.

<img />

After successfully creating your new outbound integration, you'll be redirected to the details page automatically.

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/webhook#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan:** The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an admin in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

## Configure Webhook Request

To configure webhook requests in the All Quiet incident management tool, you would typically follow these steps:

* **Load an Incident:** Choose an incident from your list to serve as a test case.
* **Write a Template:** Craft a Handlebars template that converts the incident data into a webhook request payload.
* **Review & Dispatch:** Examine the generated request for accuracy, then save and trigger a test request to confirm the integration works as expected.

### Load Incident Model for Testing

1. Select an incident. This incident acts as a sample to define how the webhook should behave.
2. Clicking on an incident will populate its JSON structure in the test area (2), allowing you to use real incident data to model the webhook request.

<img />

### Write a Template

With the incident data loaded, navigate to the `Template` section. Here, use [Handlebars syntax](https://handlebarsjs.com/guide/) to map the incident data fields to the corresponding webhook JSON structure. This template determines how the incident data is transformed into the format required by the receiving endpoint. Here, you need to add the `URL` you want to sent the Outbound Webhook to.

<img />

The following JSON structure provides a template for sending a webhook request. You can modify the `method`, `url`, `headers` values, and the `body` content to fit the specific requirements of your webhook integration.

For each new incident event, such as creation, resolution, or commenting, All Quiet will send an HTTP call with the specified method, headers, and body to the URL defined in the webhook request JSON.

```JSON theme={null}
{
    "method": "POST",
    "url": "https://your-url.com",
    "headers": {
        "Content-Type": "application/json; charset=utf-8",
        "X-Your-Header": "abc"
    },
    "body": {
        "text": "Your Text Content",
        "formData": {
            "key1": "a",
            "key2": "b"
        },
        "json": {
            "prop1": "a",
            "prop2": {
                "someArray": [{"k": "v"}]
            }
        }
    }
}
```

Only one of `text`, `formData`, and `json` is used. If you specify more than one, the first one is used.

#### Look Up Incident Attributes by Name

Incident attributes from your [payload mapping](/essentials/inbound#mapping-payloads) are available in Handlebars templates through two properties on the incident model:

* **`attributes`** — an array of attribute objects. Use this when you want to iterate over all attributes (for example with `{{#each attributes}}`), but values are only addressable by position in the list.
* **`attributesByName`** — a map keyed by attribute name. Use this to read a specific attribute without knowing its index in `attributes`.

Each entry in `attributesByName` has the same shape as an item in `attributes` (`name`, `value`, `isImage`, `hideInPreviews`, and related fields). Reference the value of a named attribute with dot notation:

```JSON theme={null}
{
    "method": "POST",
    "url": "https://your-url.com",
    "headers": {
        "Content-Type": "application/json; charset=utf-8"
    },
    "body": {
        "json": {
            "title": "{{title}}",
            "environment": "{{attributesByName.ENV.value}}",
            "server": "{{attributesByName.Server.value}}"
        }
    }
}
```

When you load an incident for testing, its JSON in the test area includes `attributesByName` alongside `attributes`, so you can confirm attribute names and values before saving your template.

<Tip>If an attribute name contains characters that are not valid in Handlebars dot paths (for example spaces or hyphens), use bracket notation: `{{attributesByName.[My Attribute].value}}`.</Tip>

### Outbound IP Addresses

The outbound IP addresses used for webhook requests are dynamic and can be retrieved from the following endpoints:

* US Region: [https://allquiet.app/api/public/v1/metadata/ips](https://allquiet.app/api/public/v1/metadata/ips)
* EU Region: [https://allquiet.eu/api/public/v1/metadata/ips](https://allquiet.eu/api/public/v1/metadata/ips)

While these IP addresses are generally stable, we do not guarantee their persistence. It's recommended to regularly check these endpoints for any changes.

### Inspect and Send Webhook Request

1. In the 'HTTP Request' section, review the final payload based on your template. This is where you ensure that all necessary data is correctly formatted and included.
2. Optionally, you can sign the request. As `Signing Method`, we currently support "HMAC-SHA256 (All Quiet)" or "HMAC-SHA256 (AWS DevOps Agent)". Don't forget to add your `Signing Secret` when adding a signature.
3. After confirming the request and selected signing method are accurate, save the mapping.
4. Use the `Trigger Dummy Request` button to test the webhook, validating the end-to-end process.
5. The recorded request and response will be visible in the right pane under "Latest Requests".

<img />

<Check> You now integrated outbound webhooks with All Quiet, simplifying incident management by consolidating notifications and actions in your place of choice.</Check>

### Update / Patch Incidents via Outbound Webhook

In addition to only sending an All Quiet incident to another tool via the Outbound Webhook, you can also use it **to patch (update) the incident** directly.
This can be valuable when you want to trigger a certain action or when you simply want to enrich the incident by sending it to your Outbound Webhook.

To allow incident patching via Outbound Webhook

1. Adjust your Outbound Webhook's [request template](/integrations/outbound/webhook#write-a-template) and add `"enableIncidentUpdates": true`.

<img />

2. Prepare a patch response from the URL you're sending the incident to. Find a few examples for patches below. The whole list of patches we allow can be retrieved via our [Public API Documentation,"IncidentResource" Patch](https://allquiet.app/api/public/swagger-ui/index.html).

<AccordionGroup>
  <Accordion title="Use Case 1: Resolve Incident When Sent to Outbound Webhook">
    To resolve an incident as soon as it's send to the outbound webhook, send this patch as response to the Outbound Webhook.

    ```

    {
    "operations": {
        "appendIntent": {
            "intent": "Resolved"
            }
        }
    }   

    ```

    The incident will be updated as `resolved` by your Outbound Webhook Integration.
  </Accordion>

  <Accordion title="Use Case 2: Add Attribute To Incident When Sent to Outbound Webhook">
    In this example we want to add a new attribute to the incident, a URL to the tool which the incident was sent to by the Outbound Webhook.

    ```

    {
    "operations": {
        "addAttributes": {
          "attributes": [
            {
              "name": "ExampleToolURL",
              "value": "https://exampleurl.com/ID",
              "isImage": false,
              "hideInPreviews": false
            }
          ]
        }
      }
    }   
    ```

    The incident will be updated a by your Outbound Webhook Integration, including the new attribute "OutboundID".
  </Accordion>
</AccordionGroup>

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# Zapier
Source: https://docs.allquiet.app/integrations/outbound/zapier

Send All Quiet Incidents to Almost Any App Using Zapier

<Info>Setup time: 10 Min</Info>

Zapier's claim is "More Integrations Than Anyone".
With this integration, you can connect All Quiet with any of Zapier's listed integrations.

<Tip> Want to use Zapier as an Inbound Integration to create incidents? Follow the first part of this outbound documentation to create the integration. Then, follow the [Zapier Inbound Integration Documentation](/integrations/inbound/zapier).</Tip>

## Create Outbound Integration

1. Click on the `Outbound Integrations` tab.
2. Click on `+ Create`.

<img />

1. Enter a `Display Name` for your integration, e.g. "Outbound Webhook".
2. Select a `Team`. <Note>For Organizations with Pro and Enterprise plan: This is going to be the root team of your integration. You will be able to add additional teams in the next step.</Note>
3. Select `Webhook` as the integration's type.
4. Forwarding settings:
   1. **Default:** `Always` will automatically forward all incidents to your Zaps, unless excluded by additional [advanced routing rules](/advanced/routing).
   2. **Alternative 1**: `Always After Forwarding` will only sent requests if users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Webhook Outbound integration that automatically forward incidents in specific scenarios. **After Forwarding, all updates** of the incident **will also be pushed to the Outbound Webhook**.
   3. **Alternative 2**: `Only On Forwarding` will only forward a snapshot of the current incident history to your Zaps in the moment users [manually forward specific incidents](/essentials/incident#forwarding) or if you set up [advanced routing rules](/advanced/routing) for your Zapier Outbound integration that automatically forward incidents in specific scenarios. We will **not send** any incident **updates** to your Zaps, **afterwards**.
      <Tip>You can change your selection anytime.</Tip>
5. Click `Create Outbound Integration`.

<img />

Once you've successfully created your new outbound integration, you'll automatically be redirected to its `Settings` page.

1. You receive the `Integration ID` that you will need on Zapier's site to connect with All Quiet.
2. You receive the `Webhook Secret` that you will need on Zapier's site to connect with All Quiet, too.

<Info> In the `Edit` tab, you can change general settings like the integration's [Forwarding settings](/integrations/outbound/zapier#create-outbound-integration). You can also enable **Anonymize Outbound Logs** (disabled by default). When enabled, activity log entries for this integration are stored without descriptions, external identifiers, error details, and payload data. Only operational metadata such as operation, outcome, and HTTP status is kept.</Info>
<Note>**Only for Pro and Enterprise plan:** The root team is pre-selected, and you can add the integration to further teams within the root team's organization. *Team Administrators* can add / remove those teams they are an admin in, *Organization Administrators* & *Organization Owners* can manage the connections to all teams of the organization. </Note>

<img />

<Tip>The following part of this documentation will explain how to use an All Quiet incident to Trigger a Zap. If you want to create an incident in All Quiet using a Zapier Action, please refer to the [Zapier Inbound Documentation](/integrations/inbound/zapier).</Tip>

## Use All Quiet as a Trigger in Zapier

You can use Zapier to connect other outbound tools to your All Quiet workflows than those for that we have [direct outbound integrations](/integrations/overview#outbound-integrations) already.

First, log in to your Zapier account.

1. On the home screen, click `Create`.
2. Select `Zaps`.

<img />

After the Zap is created, select the Trigger.

<img />

1. Search for `All Quiet`.
2. Select it.

<img />

1. After selecting the app, you need to choose an Event. As you selected All Quiet as a Trigger, you can only select `New Incident Intent`.
2. After selection, click `Continue`.

<img />

Now, you need to sign in to you All Quiet Account to connect it with Zapier.

<img />

You will have to provide your

1. Integration ID and
2. Webhook Secret
   that you received after creating the outbound integration in All Quiet.
3. Also, provide your `Data Storage Region`, either `US` or `EU`.
4. After providing the credentials, click `Yes, Continue to All Quiet`.

<img />

After signing in with All Quiet, you can continue.

<img />

Test the Trigger to see if you can load an All Quiet incident into Zapier.

<img />

1. You can select a payload that you would like to use for the test.
2. `Continue with selected record`.

<img />

## Add an Action based on the All Quiet Trigger

Now, you can select a Zap Action to trigger with you All Quiet incident.

<Info>In this example, we want to use the All Quiet Trigger to send a new email via the Zapier Gmail integration. Instead of using Gmail, you could also use other Zapier integrations for an Action.</Info>

1. Search for Gmail.
2. Select it.

<img />

Gmail is added as integration to create an Action in our Zap. Now, we have to configure it in order to use it.

<img />

1. Select an Event supported by the Gmail integration.
2. Here, we choose "Send Email".
3. Click `Continue`.

<img />

Sign in to the Gmail account you want to use to send the email.

<img />

After successful sign in, you will see the connected Gmail Account in Zapier. From here, click `Continue` to configure your action.

<img />

As we previously selected the Event "Send Email", we can now configure the email's elements. We can combine text with the elements from All Quiet incidents. Here, we see the example payload elements from the [Trigger we set up ealier](/integrations/outbound/zapier#use-all-quiet-as-a-trigger-in-zapier).

<img />

After setting up your mail, click `Continue`.

<img />

Now, you can test your Zap by sending a test mail based on your configuration and the example payload.

<img />

The result in Gmail.

<img />

If you're happy with the result, publish your Zap.

<img />

<Check>You successfully set up your Zapier Outbound Integration!</Check>

<Tip>To create new incidents in All Quiet using Zapier, check our [Zapier Inbound Integration](/integrations/inbound/zapier) documentation.</Tip>

## Troubleshooting

**Team Administrators**, **Organization Administrators**, and **Organization Owners** can troubleshoot this integration using the **History** tab (**Outbound History**) on the integration details page. See **[Outbound History](/essentials/outbound#outbound-history)** for what is logged, who can access it, and how to read outcomes. For broader checks when outbound tools do not fire, see **[Outbound integrations — Troubleshooting](/essentials/outbound#outbound-troubleshooting-routing)** and **[advanced routing](/advanced/routing)**.


# Integrations Overview
Source: https://docs.allquiet.app/integrations/overview

Integrate All Quiet with your tech stack

## Inbound Integrations

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

<CardGroup>
  <Card title="Cisco AppDynamics" icon="chart-simple" href="/integrations/inbound/appdynamics" />

  <Card title="AppSignal" icon="crown" href="/integrations/inbound/appsignal" />

  <Card title="AWS Cloudwatch" icon="cloud" href="/integrations/inbound/aws" />

  <Card title="Azure Monitor" icon="cloud" href="/integrations/inbound/azure" />

  <Card title="Checkly" icon="check" href="/integrations/inbound/checkly" />

  <Card title="Coralogix" icon="circle-dot" href="/integrations/inbound/coralogix" />

  <Card title="Cron Job Monitor" icon="circle-notch" href="/integrations/inbound/cron-job-monitor" />

  <Card title="CrowdStrike" icon="crow" href="/integrations/inbound/crowdstrike" />

  <Card title="Dash0" icon="0" href="/integrations/inbound/dash0" />

  <Card title="Datadog" icon="dog" href="/integrations/inbound/datadog" />

  <Card title="Dynatrace" icon="cube" href="/integrations/inbound/dynatrace" />

  <Card title="Elastic Observability" icon="circle" href="/integrations/inbound/elastic-observability" />

  <Card title="Email" icon="envelope" href="/integrations/inbound/email" />

  <Card title="Google Cloud Monitoring" icon="cloud" href="/integrations/inbound/gcm" />

  <Card title="GitHub" icon="github" href="/integrations/inbound/github" />

  <Card title="GitLab" icon="gitlab" href="/integrations/inbound/gitlab" />

  <Card title="Grafana" icon="chart-pie" href="/integrations/inbound/grafana" />

  <Card title="Heartbeat Monitor" icon="heart-pulse" href="/integrations/inbound/heartbeat-monitor" />

  <Card title="Honeycomb" icon="hexagon" href="/integrations/inbound/honeycomb" />

  <Card title="Jira" icon="jira" href="/integrations/inbound/jira" />

  <Card title="Linear" icon="timeline" href="/integrations/inbound/linear" />

  <Card title="Mattermost" icon="power-off" href="/integrations/inbound/mattermost" />

  <Card title="Microsoft Teams" icon="microsoft" href="/integrations/inbound/microsoft-teams" />

  <Card title="Nagios" icon="N" href="/integrations/inbound/nagios" />

  <Card title="Netdata" icon="d" href="/integrations/inbound/netdata" />

  <Card title="New Relic" icon="chart-bar" href="/integrations/inbound/newrelic" />

  <Card title="Observium" icon="think-peaks" href="/integrations/inbound/observium" />

  <Card title="Ping Monitor" icon="server" href="/integrations/inbound/ping-monitor" />

  <Card title="Pingdom" icon="sun" href="/integrations/inbound/pingdom" />

  <Card title="Prometheus" icon="fire" href="/integrations/inbound/prometheus" />

  <Card title="PRTG Network Monitor" icon="gauge-low" href="/integrations/inbound/prtg" />

  <Card title="Rollbar" icon="horizontal-rule" href="/integrations/inbound/rollbar" />

  <Card title="Salesforce" icon="salesforce" href="/integrations/inbound/salesforce" />

  <Card title="Sentry" icon="triangle" href="/integrations/inbound/sentry" />

  <Card title="ServiceNow" icon="user" href="/integrations/inbound/servicenow" />

  <Card title="SigNoz" icon="eye" href="/integrations/inbound/signoz" />

  <Card title="Site24x7" icon="square-arrow-up" href="/integrations/inbound/site24x7" />

  <Card title="Slack" icon="slack" href="/integrations/inbound/slack" />

  <Card title="Splunk" icon="greater-than" href="/integrations/inbound/splunk" />

  <Card title="StatusCake" icon="cake-slice" href="/integrations/inbound/statuscake" />

  <Card title="Twilio" icon="phone-arrow-down-left" href="/integrations/inbound/twilio" />

  <Card title="UptimeRobot" icon="robot" href="/integrations/inbound/uptimerobot" />

  <Card title="Webhook" icon="webhook" href="/integrations/inbound/webhook" />

  <Card title="Website / HTTP Monitor" icon="monitor-waveform" href="/integrations/inbound/website-http-monitoring" />

  <Card title="Zabbix" icon="square-z" href="/integrations/inbound/zabbix" />

  <Card title="Zapier" icon="integral" href="/integrations/inbound/zapier" />
</CardGroup>

## Outbound Integrations

Send alerts from All Quiet to the tools you use. We have a generic outbound webhook integration as well as a growing list of pre-built integrations like [Slack](/integrations/outbound/slack) and more:

<CardGroup>
  <Card title="Confluence" icon="confluence" href="/integrations/outbound/confluence" />

  <Card title="Discord" icon="discord" href="/integrations/outbound/discord" />

  <Card title="GitHub" icon="github" href="/integrations/outbound/github" />

  <Card title="GitLab" icon="gitlab" href="/integrations/outbound/gitlab" />

  <Card title="Google Chat" icon="google" href="/integrations/outbound/google-chat" />

  <Card title="Google Docs" icon="google-drive" href="/integrations/outbound/google-docs" />

  <Card title="Google Sheets" icon="google-drive" href="/integrations/outbound/google-sheets" />

  <Card title="Jira" icon="jira" href="/integrations/outbound/jira" />

  <Card title="Linear" icon="timeline" href="/integrations/outbound/linear" />

  <Card title="Microsoft Teams" icon="microsoft" href="/integrations/outbound/microsoft-teams" />

  <Card title="Notion" icon="n" href="/integrations/outbound/notion" />

  <Card title="Salesforce" icon="salesforce" href="/integrations/outbound/salesforce" />

  <Card title="ServiceNow" icon="user" href="/integrations/outbound/servicenow" />

  <Card title="Slack" icon="slack" href="/integrations/outbound/slack" />

  <Card title="Webhook" icon="webhook" href="/integrations/outbound/webhook" />

  <Card title="Zapier" icon="integral" href="/integrations/outbound/zapier" />
</CardGroup>

## Suggest a new integration

Didn't find your tool here? Reach out to [support@allquiet.app](mailto:support@allquiet.app) and let us know your preferred integration. We're always happy to grow our integrations list.


# Billing & Subscription
Source: https://docs.allquiet.app/miscellaneous/billing

Fair and transparent pricing for modern teams

## Trial Phase

All Quiet offers a **free 14-Day free trial**. No credit card required! After 30 days you need to subscribe to our services to continue using All Quiet effectively.

You can subscribe in the `Billing` section of your dashboard. Select between our three different pricing plans based on your needs.

<Note> The `Billing & Subscription` section is only accessible for *Billable Users* of at least one team / organization. </Note>

<img />

We are using the payment processor Stripe to process your subscription, and we'll never save your payment details on our side.

* ✅ **Risk-Free:** you can cancel any time.
* ✅ **Flexible:** change users any time.
* ✅ **Cost Management:** billed monthly.
* 🪨 **Rock-solid availability:** Our app is always on, so you can be too!

## Manage Billing & Subscription

After subscribing, you can manage your subscription and billing settings on the `Billing & Subscription` page.

1. You can easily edit your current billing address.
2. Also, you can change your payment method for future payments.
3. Your invoices will be available for download. Besides, you can edit the invoice recipients.
4. After clicking **Manage Subscription**, you're redirected to the `Manage Subscription` page. Here, you can either switch between our different plans or cancel your subscription.

<img />

`Manage Subscription` page.

<img />

### How Is The Number of Billed Users Calculated?

Billing is based on your plan and on the number of **Unique Users with Team Memberships** across all teams billed by the *Billable User*.
<Note>If you have a running subscription and no billed users, we will keep your subscription active with the minimum quantity of **1 billed user**. You can explicitly cancel your subscription at any time.</Note>
You can view all billed users under "Billing & Subscription > Your Subscription". To add / remove users, go to your [Teams'](/essentials/teams#members) membership settings.

<img />

Example:

* User A is the *Billable User* of Team 1 & 2
  * Team 1 Memberships: User A, User B, User C
  * Team 2 Memberships: User B, User D

There's a total of 4 unique users across both teams, so 4 users are being billed to User A. Pricing depends on User A's [plan](https://allquiet.app/pricing).

## How to change the Billable User

Here's how want to change the *Billable User* for your [Team](/essentials/teams) or [Organization](/advanced/organizations).

### Teams

<Tip>If the team is part of an Organization, read the [Organizations](/miscellaneous/billing#organizations) section to learn how to change the *Billable User*.</Tip>

<Steps>
  <Step title="Step 1">
    Go to the `Teams` view and select `Edit`.

    <img />
  </Step>

  <Step title="Step 2">
    Go to field `Billed by` to change the *Billable User* of the Team. You can choose other *Team Administrators* to become the new *Billable User*.
    <Warning> Be careful when changing the *Billable User*. A subscription is attached to a User, not to a Team. The new *Billable User* will have to create a new subscription and start billing for this Team. We recommend creating a subscription for the new *Billable User* before changing the *Billable User* of the Team. Otherwise, no new incidents will be created for this Team. **Exception**: The Trial is still active.</Warning>

    <img />
  </Step>
</Steps>

### Organizations

All teams in an [Organization](/advanced/organizations) have a single *Billable User*. This *Billable User* is the *Billable User* of all teams within that Organization.

<Steps>
  <Step title="Step 1">
    Go to the `Organizations` view and select `Edit`

    <img />
  </Step>

  <Step title="Step 2">
    Go to field `Billed by` to change the *Billable User* of the Organization. You can choose other *Organization Owners* to become the new *Billable User*.
    <Warning> Be careful when changing the *Billable User*. A subscription is attached to a User, not to an Organization. The new *Billable User* will have to create a new subscription and start billing for this Organization. We recommend creating a subscription for the new *Billable User* before changing the *Billable User* of the Organization. Otherwise, no new incidents will be created for Teams in this Organization. **Exception**: The Trial is still active.</Warning>

    <img />
  </Step>
</Steps>


# SSO - OpenID Connect & SCIM
Source: https://docs.allquiet.app/miscellaneous/sso

Integrate SSO using OpenID Connect (OIDC) and SCIM 2.0 for All Quiet

<Note>OpenID Connect (OIDC) and SCIM are available on Pro & Enterprise plan only.</Note>
All Quiet provides a secure and efficient way to integrate Single Sign-On (SSO) using OpenID Connect and SCIM, offering a seamless authentication experience for your users.

## OpenID Connect (OIDC)

This integration allows your organization to utilize its existing identity provider (IdP) services to manage user access to All Quiet.

### Step-by-Step-Guide

<Info>For this process, you need access SSO tab of your organization, only accessible to users with *Organization Owner* role.</Info>

<Steps>
  <Step title="Create an Organization">
    To use OIDC, you first need to create an [Organization](/advanced/organizations) in All Quiet. If you also want to use [SCIM](/miscellaneous/sso#scim-2-0) to provision your users, please note that the user ("root user") who creates the Organization cannot be provisioned through SCIM. We recommend to create the Organization with a "root user" that is not bound to a specific employee, like [devops@yourcompany.com](mailto:devops@yourcompany.com).
  </Step>

  <Step title="Setting up in Your IdP">
    In your identity provider’s management console, you will need to register All Quiet as a new application and give your users access to it.

    <Note> Make sure to create an application that uses OIDC, not SAML, as the authentication type. Also, if you want to add [SCIM provisioning](/miscellaneous/sso#scim-2-0), make sure the application supports SCIM provisioning as well.</Note>
    <Warning>When adding an OIDC tenant for **existing** All Quiet accounts, All Quiet maps users by **email address**. The email address on the All Quiet account must match the user’s **primary email address** in your Identity Provider (IdP). If they don’t match, the account cannot be mapped and the user won’t be able to sign in to the existing account in All Quiet via OIDC. Make sure to update the All Quiet email addresses accordingly (users can update their email in the Web app under `/app/account`) before adding the OIDC tenant.</Warning>

    In your IdP's application, you will need to configure the following:

    Configure the **Redirect URI** in your IdP:

    * `https://allquiet.app/signin-oidc` (US Hosted) or
    * `https://allquiet.eu/signin-oidc`(EU Hosted).

    In case that a **Login URL** is expected as well, set it to

    * `https://allquiet.app/login` (US Hosted) or
    * `https://allquiet.eu/login`(EU Hosted).

    The application will provide you with a **Client ID** and **Client Secret** that you will need in the next step to set up the application on All Quiet. Make sure to safe the information securely. Additionally, you will need to provide the **Authority URL** from your IdP's application to set up the OIDC tenant in All Quiet Web App. The Authority URL is usually the client-specific domain derived from the discovery document URL. These details are essential for establishing a secure and reliable connection between your IdP and All Quiet.

    #### OIDC with Microsoft Entra ID

    In your OIDC tenant's `API Permissions` settings, add `email`, `offline_access`, `openid` and `profile` permissions.
    Mark all these permissions as type `Delegated` and without requiring Admin consent.

    Also, in the `Token Configuration`, add `email` claims.

    **Authority URL (important):** Microsoft Entra has two OIDC endpoint versions. The Authority URL determines which discovery document and token endpoint are used.

    * **Recommended (v2.0 / Microsoft Identity Platform):** `https://login.microsoftonline.com/{tenant-id}/v2.0`\
      Use this for modern OIDC setups and scope-based permissions (like `openid`, `profile`, `email`, `offline_access`).
    * **Legacy (v1.0):** `https://login.microsoftonline.com/{tenant-id}`\
      Only use this if you have a legacy setup that explicitly requires v1.0 tokens.

    <Tip>If you’re unsure, start with the **v2.0** Authority URL. A mismatched Authority URL can cause discovery or token validation errors.</Tip>

    #### OIDC with Jumpcloud

    In your OIDC tenant's `OIDC Single Sign-On Configuration`

    * Select "Client Secret POST" as `Client Authentication Type`
    * Select Standard Scopes "Email" and "Profile". No need to further adjust the mapping of single attributes.
    * The **Authority URL** can be found [here](https://jumpcloud.com/support/sso-with-oidc).

    #### OIDC with Google Workspace

    You'll need to additionally configure the **Redirect URI**:

    * `https://allquiet.app/signin-oidc` (US Hosted) or
    * `https://allquiet.eu/signin-oidc`(EU Hosted).

    The **Authority URL** for Google is `https://accounts.google.com`.

    #### OIDC with Okta

    The **Authority URL** for Okta is `https://{tenant}.okta.com`

    #### OIDC with Auth0

    The **Authority URL** for Auth0 is `https://{tenant}.auth0.com`.
  </Step>

  <Step title="Set up OIDC Tenant in All Quiet Web App">
    After setting up the application in your IdP, you need to set up the OIDC tenant in All Quiet Web App.

    * Go to `Organizations`
    * Select your organization
    * Click on `SSO` tab
    * Click on `Submit OIDC request` button.
      <img alt="LoginOIDC" />

    Fill out the following information in the overlay window:

    1. Submit OIDC request:
       * **Associated Domains**: Enter the domains you want to associate with the OIDC tenant. Only add domains you control. You can add multiple domains by separating them with a comma. We will validate the domains you add after you submit the request.
       * Authority URL: Enter the **Authority URL** from your IdP's application that you've received in the previous step. We fetch `{authority}/.well-known/openid-configuration` to validate it.
       * Client ID: Enter the **Client ID** from your IdP's application that you've received in the previous step.
       * Client Secret: Enter the **Client Secret** from your IdP's application that you've received in the previous step. **Do not share this secret with anyone.** All Quiet will store your IdP credentials securely in our database.
       * **Secret Expires** (optional): Enter the date and time when the client secret will expire. We will remind you 2 weeks before the secret expires.
       * **Break-Glass Emails** (optional): Break-Glass Emails can be used to bypass OIDC sign-in and typically are not tight to a individual person, but rather a service account e.g. [admin@acme.com](mailto:admin@acme.com). Each email domain must match an Associated Domain you listed above (subdomains are allowed). Add multiple emails by separating them with a comma.
       * **Scopes**: Space-separated OIDC scopes. The default is `openid profile`, which works with most IdPs. For **Google Workspace**, include `email` as well — use `openid profile email`. If you're unsure, keep the default `openid profile`.

    2. Optional: Set SCIM provisioning preferences:
       If you want to set up [SCIM provisioning](/miscellaneous/sso#scim-2-0), too, let us know your preferences during this step.

       * Define if SCIM provisioned users should be allowed to **change their phone number** via the Web app.
       * Define if SCIM provisioned users need to **confirm their phone number** via the Web app. We recommend this to be enabled to ensure the phone number is valid and users can receive notifications.

       <Info>Have you already created users manually and now wish to convert them to SCIM-provisioned users? Let us know the exact users you want to convert after submitting the request by contacting [support@allquiet.app](mailto:support@allquiet.app).</Info>

    3.Click on `Submit request` button.

    <img alt="LoginOIDC" />
  </Step>

  <Step title="Verification and Activation">
    After submitting the request, our team will review your request and get back to you  if additional information is needed.

    After successful verification, the integration is considered complete. You will now find your OIDC tenant (and SCIM provisioning preferences if you've set them up) in the `SSO` tab of your organization.

    <img alt="LoginOIDC" />

    ### Renewing OIDC credentials

    Once your tenant is active, you can use **Submit an OIDC renewal request** on the `SSO` tab when you need to rotate your client secret. If your secret is about to expire, we will notify you by email. In the renewal form, provide the new **Client Secret** and, if applicable, the updated **Secret Expires** date.
  </Step>

  <Step title="Log in via OIDC">
    To log in via the All Quiet Website, your users need to

    1. Select the correct hosting region
    2. Click on `Continue with OpenID Connect`
       <img alt="LoginOIDC" />
  </Step>
</Steps>

### Conclusion

Integrating your organization's SSO using OpenID Connect with All Quiet enhances your platform's security and user experience. With this setup, you ensure a consistent and secure access management system, aligned with your organizational policies and requirements.

## SCIM 2.0

### Step-by-Step-Guide

<Info>For this process, you need access to the API Keys and SSO tab of your organization, only accessible to users with *Organization Owner* role.</Info>

This integration allows your organization to leverage tools like Microsoft Entra for smoother user management in All Quiet.

<Note>Users must be members of a User Group in your IdP that is assigned to the All Quiet application. Only users in those groups will see the application in your IdP and be provisioned to All Quiet.</Note>

<Steps>
  <Step title="Create an Organization">
    To use SCIM, you first need to create an [Organization](/advanced/organizations) in All Quiet. Please note: The user who creates the Organization cannot be provisioned via SCIM. Therefore, we recommend to create the Organization with a "root user" that is not bound to a specific employee, e.g. [devops@yourcompany.com](mailto:devops@yourcompany.com). This way, you ensure all “real” on-call users and employee accounts can be provisioned. If you already set up the Org with your personal account, you can change your account’s email address via the Web app on /app/account to a root user email and later provision your personal email and account via SCIM.
  </Step>

  <Step title="Request OIDC Tenant and SCIM provisioning via All Quiet Web App">
    OpenID Connect SSO first is a prerequisite for SCIM user provisioning. Follow the OIDC setup guide [here](/miscellaneous/sso#openid-connect-oidc) and make sure to opt-in for SCIM provisioning.
    <Info>Have you already created users manually and now wish to convert them to SCIM-provisioned users? Let us know the exact users you want to convert after submitting the request by contacting [support@allquiet.app](mailto:support@allquiet.app).</Info>
    <Info>If your organizations already has an active OIDC tenant and you want to use it for SCIM provisioning, please contact [support@allquiet.app](mailto:support@allquiet.app). Please inform us whether SCIM provisioned users should be able to change their phone number and / or confirm their phone number via the Web app.</Info>
  </Step>

  <Step title="Retrieve Base URL & API Key">
    In your SCIM provider’s console, you will need to register All Quiet as a new SSO application.

    For the integration, you will need to provide the **Base URL** and **API Key** of your All Quiet Organization.

    After approving your OIDC tenant and SCIM provisioning request, our team will create your Organization's **Base URL**. It will be visible under

    1. `Organizations`.
    2. Select your Organization and the tab `SSO`.

    <img />

    Additionally, you'll need an **API Key**. To find or create your Organization's API Key, open

    1. `Organizations`.
    2. Select your Organization and the tab `API Keys`.
    3. Retrieve your `API Key`.
    4. Alternatively, click `+ Create API Key` if you haven’t created one yet.

    <img />

    Both, **Base URL** and **API Key** will be necessary to activate All Quiet as a new SSO application of your SCIM provider and to establish a secure and reliable connection.
    All Quiet stores all secrets strongly encrypted in our database to ensure the safety of your credentials.

    Make sure to select the Users and User Groups you want to share with All Quiet in your SCIM provider's interface and activate the SCIM provisioning.
  </Step>

  <Step title="Verification and Testing">
    Once the setup is completed, you will find the users provisioned via SCIM under

    1. Organizations
    2. Tab `Associated Users`. The `Source` column will show which users got provisioned via SCIM.

    <img />
  </Step>

  <Step title="Log in via OIDC">
    Your SCIM provisioned users can now log in via OIDC. They won't have a password, so they need to use the OIDC login button to log in.

    To log in to All Quiet, your users need to

    1. Select the correct hosting region
    2. Click on `Continue with OpenID Connect`

    <img />
  </Step>

  <Step title="SCIM Team & Organization Role Provisioning">
    You can use the User Groups from your SCIM provider for Team & Organization Management in All Quiet. This is a convenient and much leaner alternative to [manual team invites](/essentials/teams#inviting-members) for larger organizations.

    Go to `Organizations > SSO.`

    **Manual Provisioning Mode**

    1. First, you need to select your `Provisioning Mode`. We recommend `Manual Provisioning` if you want to be flexible and want to be able to switch SCIM User Groups between All Quiet Teams.
       <Warning>Switching the **Provisioning Mode** between **Manual** and **Auto** will remove all previously provisioned users from their teams, as this action resets the existing mappings. To avoid disruptions, we recommend choosing a provisioning mode and sticking with it.</Warning>
    2. Find your SCIM User Groups below.
    3. Optionally, you can assign *Organization Member*, *Organization Administrator* or *Organization Owner* roles to the provisioned users.
    4. Map your SCIM User Groups to All Quiet Teams. For Manual Provisioning Mode, there have to be existing teams for you to be able to map them.
       <Tip>Changing an existing mapping will add Users to other All Quiet Teams and / or remove them from their old Teams, depending on your selection. If you use [the Teams section to invite Users](/essentials/teams#inviting-members) from your SCIM Groups to your All Quiet Teams, those users will remain in the Team, even if you later remove their SCIM Group from the Team.</Tip>
    5. Choose whether provisioned users should be assigned *Member* or *Administrator* roles within the teams. You can update these roles via the Teams section at any time for each User. Learn more about team roles [here](/essentials/teams#roles).
    6. Save your settings. You will find the Users from your SCIM User Groups in your All Quiet Teams.

    <img />

    **Auto Provisioning from Groups**

    1. In this case, we've selected **Auto Provisioning from Groups** as provisioning mode. For this mode you don't have to create All Quiet teams in advance. However, it's also much stiffer.
    2. Auto Provisioning options include a **Group Provisioning Filter**: You can use this field if you only want certain SCIM User Groups to be auto provisioned to All Quiet Teams.
    3. **Default Team Role**: Choose whether provisioned users should be assigned *Member* or *Administrator* roles within the **Teams**.
    4. **Default Organization Role**: You can additionally assign *Member*,*Administrator*  or *Owner* roles within the **Organization**.
    5. A preview showing which SCIM User Groups will create which All Quiet Teams.
    6. Again, safe to create the teams and roles through auto provisioning mode.

    <img />
  </Step>
</Steps>

### Provisioned Users Cannot Be Edited via Web App.

To ensure that the resources managed via your SCIM provider stay in sync with your setup, we lock provisioned resources within the Web App. This means these resources cannot be edited or deleted directly through the Web App's interface.

Provisioned resources are marked with an icon, and hovering over it will display a message explaining why the resource is locked and cannot be modified via the Web App.

<img />

<Tip>Exception: Depending on your organization's settings, SCIM provisioned users can still add / change their phone number via the Web App. They can also manage their [personal notification preferences](/essentials/channels#customizable-notification-preferences). When provisioning phone numbers from your Identity Provider (IdP), All Quiet imports the **primary** phone number by default and only falls back to the **secondary** phone number field if the primary field is empty.</Tip>

Your current settings can be found on the `SSO` page of your organization. If you want to change your settings, please contact [support@allquiet.app](mailto:support@allquiet.app).

<img />


# Troubleshooting & FAQs
Source: https://docs.allquiet.app/miscellaneous/troubleshooting

Self-serve answers for common setup questions

This page lists **common questions** and where to find answers in the documentation. For integration-specific issues, check the **Hints**, **Troubleshooting**, or FAQ sections at the bottom of the relevant [integration guide](/integrations/overview).

**Inbound** topics (webhook, **Latest Payloads**, discard, correlation) are grouped separately from **alerting** (personal channels, outbound tools, **routing**) and **Live Call Routing** (inbound phone calls) so the tables stay easy to scan as we add more guides.

## On-call, schedules, and rotations

| Question                                                                                                                                                                                                           | Where to look                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| How do I cover **one weekend** with a single on-call person from **Friday evening through Monday morning**, and rotate **after** Monday morning (when shifts are shorter than 24h there is **no** `Handoff Time`)? | [Escalations — Weekend on-call through Monday morning](/essentials/escalations#weekend-on-call-through-monday-morning)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
| How do I set **on-call times**, **overnight** windows, and **which weekdays** a schedule applies to?                                                                                                               | [Escalations — Schedules](/essentials/escalations#schedules)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
| How do **weekly rotations**, **handoff day**, and **`Handoff Time`** work?                                                                                                                                         | [Escalations — Auto Rotations](/essentials/escalations#auto-rotations)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
| Where is the **team time zone** configured, and how does it affect schedules?                                                                                                                                      | [Escalations — Timezones](/essentials/escalations#timezones) and [Teams — Edit Team](/essentials/teams#edit-team)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| How can I have **different escalations** for **different severities**?                                                                                                                                             | [Escalations — Automatic escalation](/essentials/escalations#automatic-escalation) (filter auto-escalate and auto-assign by severity); for a **separate on-call path** per severity, [route to different teams](/advanced/routing) ([shared integration setup](/essentials/inbound#how-to-use-one-integration-for-several-teams))                                                                                                                                                                                                                                                                                                                                                             |
| Can I have **different escalations** for **one team**?                                                                                                                                                             | In All Quiet, each team has **one escalation policy**. Within that policy you can define different [schedules](/essentials/escalations#schedules), [rotations](/essentials/escalations#rotations), and [rules for escalating to higher tiers](/essentials/escalations#automatic-escalation). If you need **different Tier 1 on-call**, or different **repeat** and **auto-escalation** rules for different kinds of incidents (for example by severity or service), create **separate teams**—each with its own escalation policy—and [route incidents](/advanced/routing) from [one shared integration](/essentials/inbound#how-to-use-one-integration-for-several-teams) to the right team. |
|                                                                                                                                                                                                                    |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |

## Alerting: Routing, Channels, and Outbound

| Question                                                                                                             | Where to look                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| -------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| A **new incident** exists but **nobody was notified**—what should I check?                                           | [Inbound — New incident, no notification](/essentials/inbound#new-incident-exists-but-still-no-notification)                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
| How do **routing rules** affect **channels**, **outbound integrations**, **snooze**, or **discard**?                 | [Advanced Incident Routing](/advanced/routing)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| My **outbound** tools (Slack, Jira, webhooks, …) don't receive the incident. What could be blocking them?            | [Outbound — Integrations never fire](/essentials/outbound#outbound-troubleshooting-routing)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
| Why did an **outbound integration** not post or update (Slack, Jira, webhook, …)—and where do I see what it tried?   | [Activity history (History tab)](/essentials/outbound#outbound-history), [Troubleshooting with activity history](/essentials/outbound#troubleshooting-with-activity-history), and [Incident — Outbound Integration Activity](/essentials/incident#incident-details-outbound-integration-activity)                                                                                                                                                                                                                                                                                         |
| **Microsoft Teams** on-call tagging or dedicated channels don't work.                                                | [Microsoft Teams — Graph permissions](/integrations/outbound/microsoft-teams#microsoft-teams-graph-permissions) (integrations connected before August 10, 2026)                                                                                                                                                                                                                                                                                                                                                                                                                           |
| I get **no personal** alerts (email, SMS, push, voice) even though the incident exists. What could be blocking them? | [Alerting channels — Troubleshooting](/essentials/channels#troubleshooting-no-personal-channel-alerts-email-sms-push-voice)                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
| Why was the **wrong team** paged—or why does only one team get alerts from a **shared** inbound integration?         | [Inbound — One integration for several teams](/essentials/inbound#how-to-use-one-integration-for-several-teams) and [Advanced Incident Routing](/advanced/routing)                                                                                                                                                                                                                                                                                                                                                                                                                        |
| Can we **extend or customize** how long **notification**, **routing**, or **outbound** activity logs are kept?       | Default retention is **30 days** (notification and routing) and **14 days** (outbound) — see [Notification History](/essentials/incident#incident-notification-history-retention-and-availability), [Routing rule executions](/essentials/incident#incident-routing-executions-retention-and-availability), and [Outbound Integration Activity](/essentials/incident#incident-outbound-activity-retention-and-availability). **Enterprise** deals can include custom retention (similar to [audit logs](/advanced/auditing)); contact [support@allquiet.app](mailto:support@allquiet.app) |

## Inbound: Payloads and Incidents

| Question                                                                                                                             | Where to look                                                                                                                                                                                                           |
| ------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| How does **payload mapping** work (`Discard`, `CorrelationId`, preview)?                                                             | [Inbound — Mapping payloads](/essentials/inbound#mapping-payloads)                                                                                                                                                      |
| An **alert did not show up** the way I expected—where do I start?                                                                    | [Inbound — Troubleshooting overview](/essentials/inbound#troubleshooting-missing-or-unexpected-incidents)                                                                                                               |
| I don’t see my payload in **Latest Payloads**, or how do I **open the incident** from a payload tile?                                | [Inbound — Latest Payloads](/essentials/inbound#latest-payloads-see-which-incident-received-the-payload)                                                                                                                |
| Why was there **no incident**—was the payload **discarded** (mapping, routing, or maintenance)?                                      | [Inbound — Payload discarded](/essentials/inbound#the-payload-was-discarded)                                                                                                                                            |
| Why did the payload **update an old open incident** instead of creating a new one, or why are there **no notifications** on updates? | [Inbound — Existing incident updated](/essentials/inbound#https://localhost:3000/essentials/inbound#the-payload-updated-an-existing-incident-and-no-notification-was-sent)                                              |
| How do I use **one integration** (one webhook URL) for **several teams**, each with its own on-call and escalations?                 | [Inbound — One integration for several teams](/essentials/inbound#how-to-use-one-integration-for-several-teams)                                                                                                         |
| How do I route alerts from the **same source** to **different teams** by severity, service, environment, or other payload fields?    | [Inbound — One integration for several teams](/essentials/inbound#how-to-use-one-integration-for-several-teams) and [payload mapping](/essentials/inbound#mapping-payloads)                                             |
| Why was **nobody paged** when the incident was created in our **Root** (central) team?                                               | [Inbound — One integration for several teams](/essentials/inbound#how-to-use-one-integration-for-several-teams) — the Root team usually has **no on-call**; confirm **Assign to Team** [routing](/advanced/routing) ran |

## Live Call Routing

| Question                                                                       | Where to look                                                                                                                                          |
| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Can I **buy a phone number through All Quiet**?                                | [Live Call Routing — Buying a number](/advanced/live-call-routing#can-i-buy-a-phone-number-through-all-quiet)                                          |
| Can All Quiet create **incidents for missed calls**?                           | [Live Call Routing — Incidents for missed calls](/advanced/live-call-routing#can-all-quiet-create-incidents-for-missed-calls)                          |
| A **call went through** but **no incident** was created — what should I check? | [Live Call Routing — Call connects but no incident](/advanced/live-call-routing#call-connects-but-no-incident-was-created)                             |
| **Nobody gets rung** when someone dials our hotline number.                    | [Live Call Routing — Nobody gets rung](/advanced/live-call-routing#nobody-gets-rung-when-someone-calls-the-hotline)                                    |
| The **same on-call person** always seems to be rung **first**.                 | [Live Call Routing — Same person rung first](/advanced/live-call-routing#the-same-person-always-seems-to-be-rung-first)                                |
| A **second caller** ringing at the same time **always gets voicemail**.        | [Live Call Routing — Second simultaneous caller gets voicemail](/advanced/live-call-routing#a-second-simultaneous-caller-always-gets-voicemail)        |
| We **paused** the number in All Quiet but callers **still get through**.       | [Live Call Routing — Pausing in Twilio](/advanced/live-call-routing#the-number-still-receives-calls-after-“pausing”-in-all-quiet)                      |
| More Live Call Routing setup and operational questions.                        | [Live Call Routing — Troubleshooting](/advanced/live-call-routing#troubleshooting) and the full [Live Call Routing](/advanced/live-call-routing) guide |

## Account, access, and billing

| Question                                                                                                                                                                                               | Where to look                                                                                 |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- |
| How do **trial**, **subscription**, and **invoices** work?                                                                                                                                             | [Billing & Subscription](/miscellaneous/billing)                                              |
| How do I set up **SSO** (OIDC / SAML) or **SCIM**?                                                                                                                                                     | [Single Sign-On (SSO)](/miscellaneous/sso)                                                    |
| I **subscribed**, but **inbound webhooks**, **Terraform**, **Public API** or **[Live Call Routing](/advanced/live-call-routing)** still return **402** while the app shows an **active subscription**. | [Subscribed but webhooks still return 402](#subscribed-but-webhooks-and-api-still-return-402) |

### Subscribed but webhooks and API still return 402

<span />

After you subscribe, **inbound webhooks**, **Terraform**, **Public API** and **[Live Call Routing](/advanced/live-call-routing)** may still return **402** for a few minutes, even though **Billing & Subscription** already shows an active subscription. This is a **cache delay** — common if your **trial had expired** before you subscribed.

The app reads subscription status without that cache, so Billing can look active while webhooks still reject traffic. Expect this to clear within about **\~5 minutes**. If **402** responses continue much longer, contact [support@allquiet.app](mailto:support@allquiet.app).

## Still stuck?

Contact [support@allquiet.app](mailto:support@allquiet.app) and mention your team name and what you already tried—we’re happy to help.


# Quickstart
Source: https://docs.allquiet.app/quickstart

Get up and running with All Quiet in under 15 minutes

## Basics

Jumpstart your team's incident management with All Quiet in just a few easy steps:

1. [Sign up](https://allquiet.app/signup/start-free-trial) for an account. It's **free for 14 days** and no credit card is required!
2. [Create a team](https://allquiet.app/app/teams/new) and pick a name for it, e.g. "My Product Team".
3. [Invite your colleagues](https://allquiet.app/app/teams) to your team. Collaborate, resolve, and build together.
4. Set up an  [inbound integration](https://allquiet.app/app/integrations/inbound/new) with your observability tool, e.g. AWS Amazon CloudWatch.
5. [Download the All Quiet app](https://allquiet.app/download-app) for your mobile phone. Customize your [notification channels](https://allquiet.app/app/account/notifications) like SMS, Voice Call, E-Mail as well as [outbound integrations](https://allquiet.app/app/integrations/outbound/new) like Slack, Discord, generic webhook and more. You'll be notified about new incidents in the dedicated channels you configured to ensure alerts being responded to.

You're now all set ✅.

## All Quiet's Core Components

Discover the building blocks of All Quiet and tailor your incident escalation workflow to fit your team's unique needs.

<CardGroup>
  <Card title="Teams" icon="people-group" href="/essentials/teams">
    Teams are at the heart of All Quiet and the means of organizing collaborators & integrations.
  </Card>

  <Card title="Escalations, Schedules & Rotations" icon="calendar" href="/essentials/escalations">
    Effortlessly configure your team's escalation policies and on-call rotation.
  </Card>

  <Card title="Alerting Channels" icon="bell" href="/essentials/channels">
    Personalize how each team member receives alerts to ensure no incident goes unnoticed.
  </Card>

  <Card title="Integrations" icon="plug" href="/essentials/inbound">
    Seamlessly connect All Quiet with the tools your team uses and loves.
  </Card>
</CardGroup>