doc/operations/incident_management/manage_incidents.md
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
This page collects instructions for all the things you can do with incidents or in relation to them.
You can create an incident manually or automatically.
{{< details >}}
{{< /details >}}
To add an incident to an iteration:
Alternatively, you can use the /iteration quick action.
Prerequisites:
To create an incident from the Incidents page:
Prerequisites:
To create an incident from the Work items page:
Create an incident issue when viewing an alert. The incident description is populated from the alert.
Prerequisites:
To create an incident from an alert:
After an incident is created, to view it from the alert, select View incident.
When you close an incident linked to an alert, GitLab changes the alert's status to Resolved. You are then credited with the alert's status change.
{{< details >}}
{{< /details >}}
In the project settings, you can turn on creating an incident automatically whenever an alert is triggered.
{{< history >}}
{{< /history >}}
You can set up a webhook with PagerDuty to automatically create a GitLab incident for each PagerDuty incident. This configuration requires you to make changes in both PagerDuty and GitLab.
Prerequisites:
To set up a webhook with PagerDuty:
To confirm the integration is successful, trigger a test incident from PagerDuty to check if a GitLab incident is created from the incident.
To view a list of the incidents:
To view an incident's details page, select it from the list.
{{< history >}}
{{< /history >}}
Whether you can view an incident depends on the project visibility level and the incident's confidentiality status:
Assign incidents to users that are actively responding.
Prerequisites:
To assign a user:
See the incidents list topic for a full description of the severity levels available.
Prerequisites:
To change an incident's severity:
You can also change the severity using the /severity quick action.
{{< history >}}
incident_escalations. Disabled by default.incident_escalations removed in GitLab 15.1.{{< /history >}}
Prerequisites:
To change the status of an incident:
Triggered is the default status for new incidents.
{{< details >}}
{{< /details >}}
On-call responders can respond to incident pages by changing the status.
Changing the status has the following effects:
In GitLab 15.1 and earlier, changing the status of an incident created from an alert also changes the alert status. In GitLab 15.2 and later, the alert status is independent and does not change when the incident status changes.
{{< details >}}
{{< /details >}}
Prerequisites:
To change the escalation policy of an incident:
By default, new incidents do not have an escalation policy selected.
Selecting an escalation policy changes the incident status to Triggered and begins escalating the incident to on-call responders.
In GitLab 15.1 and earlier, the escalation policy for incidents created from alerts reflects the alert's escalation policy and cannot be changed. In GitLab 15.2 and later, the incident escalation policy is independent and can be changed.
Prerequisites:
To close an incident, in the upper-right corner, select Incident actions ({{< icon name="ellipsis_v" >}}) and then Close incident.
When you close an incident that is linked to an alert, the linked alert's status changes to Resolved. You are then credited with the alert's status change.
Turn on closing an incident automatically when GitLab receives a recovery alert from an HTTP or Prometheus webhook.
Prerequisites:
To configure the setting:
When GitLab receives a recovery alert, it closes the associated incident. This action is recorded as a system note on the incident indicating that it was closed automatically by the GitLab Alert bot.
Prerequisites:
To delete an incident:
Alternatively:
Because incidents in GitLab are built on top of issues, they have the following actions in common: