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.

​
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 Titleby clicking on Urgency.

​
Filtering incidents

You can filter the list of incidents based on:
  • Status: Openor Resolved
  • Severity: Critical, Warning or Minor
  • Team: Choose between all of your teams here
  • Integration: Choose between all of your integrations here
  • On-Call / 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 (available only with Organizations).
To filter any of these, click on the attribute you’d like to filter and choose what you’d like to filter for. In this example, we are filtering for open incidents with severity Warning from team My First Team and integration Datadog PROD:

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

​
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.
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, and the user who cretead the incident - if it’s a manually created incident.

​
Include Snoozed Incidents

Per default, snoozed incidents 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 the incident to inform your on-call colleagues about this incident.

​
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.
Add the incident details
  1. Add a Status for the incident.
  2. Add Severity.
  3. Add a Title.
  4. Select one of your Organizations or “No organization”. Depending on your selection, you will see the related Teams and Users below.
    Only visible for users of organizations.
  5. Select the Team you want to create the incident in. After creation, on-call team members will be notified. If you selected an Organization in step 4, you can select (No Team), but than have to assign the incident to at least one specific user in step 7.
  6. 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.
  7. If you selected an Organization in step 4, 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.
    Only available for users of organizations.
  8. If the incident directly affects the functionality of one of your services, you can flag this, here.
    Only visible for users of status pages.
  9. Optionally, you may add some notes to further describe the incident.
  10. Select if you want to share your comment with the subscribers of the status pages attached to your service.
    Only visible when selecting at least one service in step 8.
  11. Create the incident.
After creation, the incident is added to the incidents overview and behaves exactly as the incidents that are automatically created from your inbound integrations. You can perform the same actions and workflows for both types of incidents.

​
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. 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. Once you’ve made your choice, simply save your changes. 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.
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!

​
Quick Actions

​
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.
For status page users: If an incident is currently affecting at least one service, resolving it will also automatically update the related services and status pages.

​
Investigating

  1. 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. Auto-escalations are stopped if your settings say “Stop Auto-Escalation” if “Incident is acknowledged”.

​
Escalating

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

​
Action with Comment

In case you want to add a comment to your action, select Comment. An overlay opens.
  1. Select the Action you would like to perform.
  • Comment: Simply add a comment with context. Marks the incident as acknowledged. Auto-escalations are stopped if your settings say “Stop Auto-Escalation” if “Incident is acknowledged”.
  • Investigate: For more info, see section Investigating.
  • Escalate: For more info, see section Escalating.
  • Resolve: For more info, see section Resolving.
  • Reopen: Only visible if an incident is in state resolved. For more info, see section Reopening Incidents.
  1. Add your comment.
    Only visible for users of status pages and if the incident is currently affecting at least one Service.
  2. You can decide whether you want to publicly share the comment on your Status Pages.
  3. Comment
Next, you will see the action plus the comment in your incident history.
For status page users: If your decided to share the comment publicly, we will add a litte Public flag.

​
Advanced Actions

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

​
Forwarding

You can manually forward single incidents to your team’s Outbound Integrations. First, click “Forward”.
You will only see the Forward button if you activated the Triggers Only On Forwarded feature for at least one Outbound Integration. Else, we will automatically forward incidents to your outbound integrations. The setup can defined in each integration’s details page.
After clicking Forward in the incidents details view, you can select the outbound integration you want to forward the issue to. Incidents can always be forwarded, even after they are resolved.
In case they are still active, this action does not stop auto-escalations.

​
Affects Services

Only visible for users of status pages.
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. In case you prepared Message Templates for the affected service, you will find them here and can select them per click.
  3. Optionally, you may add a comment. Here, we used the template.
  4. You can decide whether you want to publicly share the comment on your Status Pages.
  5. Click Affect.
In case they are still active, this action does not stop auto-escalations.
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. By marking the incident as affecting, it will also be diplayed on your 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.

​
Assign

Only available for users of Pro and Enterprise plans.
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. 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. 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.
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.
Using “assign to teams” can have an impact on the team(s) auto-escalations. Learn more, here

​
Assign to User

Need assistance from a specific colleague? No worries! With the Assign to User action, you can notify them anytime.
This part focuses on assigning an existing incident to a specific user. Want to create a new incident for a specific user? Learn more.
  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. 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.
On the incident details view
  1. You can see the assign action in the history. Not 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.
Of course, assign to user and assign to team can be combined.

​
Manually Snooze / Unsnooze

If you need time to investigate an incident and want to temporarily stop alerts, use theSnooze action to pause escalations. You can snooze
  1. for a pre-defined time
  2. until a certain date and time
  3. or indefinitely
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 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) or continue (if manually snoozed).

​
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 sidebar navigation.
Archiving an incident possibly stops auto-escalations, depending on your settings.
  1. Archive view —> All archived incidents.
  2. Archived incidents can always be Unarchived. Then, they will be visible on the incidents overview, again.

​
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. 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).
For status page users: If an incident is currently affecting at least one service, reopening it will also automatically update the related services and status pages.

​
Incident History

The “History” section in the incident details transparently shows you all details of the incident response. It is split in 4 sections.
  • Events (1)
  • On-Call Users (2)
  • Teams (3)
  • Whether the incident was already acknowledged or not (4)

​
History - Events

This section chronologically lists all events related to an incident, including updated values for attributes based on subsequent payloads linked to the incident. 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, any potential auto-escalations are stopped. If your settings stop auto-escalations if incident is resolved, 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. Once set up, incidents with matching values for the defined grouping key attributes will be grouped. 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. On the incident details view
  1. You can view the overall state 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, any new incidents matching the defined criteria (e.g., attribute UTM = 333) will be added to the group. Exception: When using groupingWindowInSeconds, new incidents will only be grouped as long as they are created within the defined groupingWindowInSeconds. After the window has ended, incidents will create new groups and alert your on-call colleagues again.
  3. You can see all single incidents that are part of the group with their status & attributes. If there were attribute changes to the subincident due to subsequent payloads, they are also listed in this section.
  4. The 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. Exception: When using groupingWindowInSeconds, new incidents that come in during the window will reopen a previously resolved group.
Advanced Routing Rules will always only be applied on group level. If they are based on certain attributes, these attributes have to be grouping keys.