Incident Collaboration

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 to see all incidents of your teams.

​

Filtering and Sorting incidents

You can filter, sort and search incidents within All Quiet.

​

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

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.

​

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 Title.
2. Add a Status for the incident.
3. Add Severity.
4. Select the Team you want to create the incident in. After creation, on-call team members will be notified.
5. 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 All Quiet.
6. Only visible for users of status pages.
   If the incident directly affects the functionality of one of your services, you can flag this, here.
7. Optionally, you may add some notes to further describe the incident.
8. Only visible when selecting at least one service in step 6.
   Select if you want to share your comment with the subscribers of the status pages attached to your service.
9. 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.

​

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.

​

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 stop auto-escalations for this incident.

​

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 initiates / sustains auto-escalations.

​

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. Stops auto-escalations for this incident.
• 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.

2. Add your comment.
3. Only visible for users of status pages and if the incident is currently affecting at least one Service.
   You can decide whether you want to publicly share the comment on your Status Pages.
4. Comment

Next, you will see the action plus the comment in your incident history.

​

Advanced Actions

Special operations are forwarding (1), affecting (2), assigning (3) and archiving (4) incidents.

​

Forwarding

You can manually forward single incidents to your team’s Outbound Integrations. First, click “Forward”.

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.

​

Affects Services

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.

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 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?

With the Assign action, you can update the teams assigned to an incident.

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

1. 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. Click on 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. Learn more in the examples below.

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.

​

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.

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: Auto-escalations stop as soon as anyone acknowledges the incident after it was assigned to Team B.

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 acknowledged the incident before assigning 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: Auto-escalations stop in both teams as soon as anyone acknowledges the incident after it was assigned to Team A & B.

​

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.

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

​

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. It also shows the user, 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, Archives or Resolves an incident, is gets marked as acknowledged. At this point, any potential auto-escalations are stopped.

For a previously acknowledged incident, Escalating, Reopening or Assigning it to a new / extra team 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.