doc/operations/incident_management/incidents.md
{{< details >}}
{{< /details >}}
An incident is a service disruption or outage that needs to be restored urgently. Incidents are critical in incident management workflows. Use GitLab to triage, respond, and remediate incidents.
When you view the incidents list, it contains the following:
State: To filter incidents by their state, select Open, Closed, or All above the incident list.
Search: Search for incident titles and descriptions or filter the list.
Severity: Severity of a particular incident, which can be one of the following values:
Incident: The title of the incident, which attempts to capture the most meaningful information.
Status: The status of the incident, which can be one of the following values:
In the Premium or Ultimate tier, this field is also linked to on-call escalation for the incident.
Date created: How long ago the incident was created. This field uses the
standard GitLab pattern of X time ago. Hover over this value to see the exact date and time formatted according to your locale.
Assignees: The user assigned to the incident.
Published: Whether the incident is published to a status page.
For an example of the incident list in action, see this demo project.
The incident list shows incidents sorted by incident created date, showing the newest first.
To sort by another column, or to change the sorting order, select the column.
The columns you can sort by:
To filter the incident list by author or assignee, enter these values in the search box.
The summary section for incidents provides critical details about the incident and the contents of the issue template (if selected). The highlighted bar at the top of the incident displays from left to right:
Below the highlight bar, a summary includes the following fields:
full_queryThe incident summary can be further customized using GitLab Flavored Markdown.
If an incident is created from an alert that provided Markdown for the incident, then the Markdown is appended to the summary. If an incident template is configured for the project, then the template content is appended at the end.
Comments are displayed in threads, but can be displayed chronologically by toggling on the recent updates view.
When you make changes to an incident, GitLab creates system notes and displays them below the summary.
{{< details >}}
{{< /details >}}
In many cases, incidents are associated to metrics. You can upload screenshots of metric charts in the Metrics tab:
When you upload an image, you can associate the image with text or a link to the original graph.
If you add a link, you can access the original graph by selecting the hyperlink above the uploaded image.
Incidents show the details of linked alerts in a separate tab. To populate this tab, the incident must have been created with a linked alert. Incidents created automatically from alerts have this field populated.
Incident timelines give a high-level overview of what happened during an incident, and the steps that were taken for it to be resolved.
Read more about timeline events and how to enable this feature.
{{< details >}}
{{< /details >}}
To see the latest updates on an incident, select Turn recent updates view on ({{< icon name="history" >}}) on the comment bar. Comments display un-threaded and chronologically, newest to oldest.
{{< details >}}
{{< /details >}}
You can enable the Service Level Agreement Countdown timer on incidents to track the Service Level Agreements (SLA) you hold with your customers. The timer is automatically started when the incident is created, and shows the time remaining before the SLA period expires. The timer is also dynamically updated every 15 minutes so you do not have to refresh the page to see the time remaining.
Prerequisites:
To configure the timer:
After you enable the SLA countdown timer, the Time to SLA column is available in the
incidents list and as a field on new incidents. If
the incident isn't closed before the SLA period ends, GitLab adds a missed::SLA
label to the incident.