---
title: "Incidents"
description: "Declare an incident, post updates to your status page and subscribers, attach evidence, resolve it, and publish a postmortem."
url: "https://support.outpostplatform.com/service-desk/incidents/"
product: "depot"
type: "how-to"
status: "draft"
ai_summary: "Incidents in the Outpost console (Enterprise and MSP). Statuses investigating, identified, monitoring, resolved, postmortem, forward only with reopen to monitoring. Severities minor, major, critical. Components and impact, commander and responders, published updates, linked alerts and tickets, files up to 25 MB (root cause analysis, evidence), postmortem with action items, templates, and metrics."
availability:
  plans: ["enterprise", "msp"]
  permission: "incident:manage"
  preview: false
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/service-desk/incidents.md"
license: "CC BY 4.0"
---

# Incidents

An incident is a problem with a service your users depend on, such as email
being down or a line-of-business application being slow for everyone. You
declare it, name who is running it, and post updates that reach your
[status page](/service-desk/status-pages/), its subscribers, and the Outpost
tray app on your endpoints. This page explains how an incident works and how
to run one from declaration to postmortem.

An incident is separate from an [alert](/service-desk/alerts/). An alert is
raised by Outpost about one endpoint. An incident is declared by a person
about a service, because what customers are told needs a human decision.

## How an incident works

### Statuses

| Status | Meaning |
| --- | --- |
| **Investigating** | The problem is known and its cause is not. Every incident starts here. |
| **Identified** | The cause is known and a fix is in progress. |
| **Monitoring** | A fix is in place and you are watching it. |
| **Resolved** | The incident is over. |
| **Postmortem** | The analysis is published. |

An incident moves forward only, and it can skip statuses, so an incident
understood straight away can go from **Investigating** to **Resolved**. There
are two exceptions:

- A resolved incident can be reopened. It goes back to **Monitoring**, because
  a fix that was believed to hold did not.
- **Postmortem** is reached only from **Resolved**, by publishing the
  postmortem.

### Severities

Every incident is **Minor**, **Major**, or **Critical**. Severity is your
judgment of the impact and appears on the status page beside the incident.

### Components and impact

[Components](/service-desk/status-pages/#components) are the parts of your
service that a status page reports on, such as "Email" or "Customer portal".
An incident names the components it affects and the impact on each:
**Degraded**, **Partial outage**, or **Major outage**. While the incident is
open, the status page shows each affected component at its impact.

### Who sees what

| What | Console | Tray app on your endpoints | Public status page and subscribers |
| --- | --- | --- | --- |
| The incident | Yes | Yes, open incidents and those resolved in the last 7 days | Only when **Show this incident on the public status page** is selected |
| Published updates | Yes | Yes | Yes, when the incident is public |
| Unpublished updates | Yes | No | No |
| **Internal notes** | Yes | No | No |
| Files | Yes | No | Only files published on the status page |

Updates cannot be edited or deleted after they are posted. A correction is
the next update.

## Before you begin

- Your plan must include the service desk: Enterprise or MSP. See
  [Plans and limits](/account/plans-and-limits/).
- To read incidents, you need `incident:read`. To declare and run them, you
  need `incident:manage`. See
  [Roles and permissions](/depot/roles-and-permissions/).
- If customers will follow the incident, set up components and turn on the
  status page first. See [Status pages](/service-desk/status-pages/).

## Declare an incident

1. Select **Incidents** > **All incidents**, then **Declare incident**. On the
   MSP plan, open the client first. For an incident that affects every client,
   see [Estate status](/service-desk/status-pages/#estate-status).
2. Optional: in **Start from a template**, choose a template. It fills the
   empty boxes and never clears what you typed.
3. Enter a **Title** and choose a **Severity**.
4. To publish the incident, select **Show this incident on the public status
   page**. Leave it clear to keep the incident inside the console.
5. Optional: enter a **Public summary** for customers, a **First update**, and
   **Internal notes** for your team. Select **Publish this update** to send
   the first update to subscribers.
6. Under **Affected components**, choose an impact for each component the
   incident affects. A component left on **No impact** is not changed.
7. Under **Who is running this**, choose a **Commander** and select any
   **Responders**. An incident has at most one commander.
8. Select **Declare incident**.

A public incident appears on the status page the moment it is declared.

You can also open an incident from an alert with **Promote to incident**. See
[Alerts](/service-desk/alerts/#promote-an-alert-to-an-incident).

## Post an update

1. Open the incident. The **Timeline** tab opens.
2. In **Post an update**, choose a status in **Move to**, or leave **Leave the
   status alone** to post a note without changing status.
3. Write the **Update**.
4. To send it to subscribers and show it on the status page, select **Publish
   this update**. An unpublished update is an internal note.
5. Select **Post update**.

To change the affected components or their impact, select **Edit impact**. To
change the commander or responders, select **Edit roles**.

## Link alerts and tickets

On the **Timeline** tab:

- **Alerts that led here** lists linked alerts. Enter the alert's ID in **Link
  an alert** and select **Link**, or select **Unlink** to remove one.
- **Tickets** lists linked tickets and their relationship: **Attached**,
  **Action item**, **Problem**, or **Change**. Enter the ticket's ID in
  **Attach a ticket** and select **Attach**, or select **Detach**. A
  technician can also attach a ticket from the ticket's **Related** tab with
  **Attach to incident**.

## Attach files

Attach a root cause analysis, logs, screenshots, or anything else that
documents the incident. Each file can be up to 25 MB.

1. On the **Timeline** tab, under **Files**, choose a **Kind**: **Root cause
   analysis**, **Evidence**, or **Other**.
2. To let anybody download the file from the status page, select **Publish
   this file on the status page**. It is off by default.
3. In **Upload**, choose the file.

Deleting a file stops it being downloadable, including from the status page.

## Resolve the incident

1. In **Post an update**, choose **Resolved** in **Move to**.
2. Write what fixed it, select **Publish this update** if customers follow the
   incident, and select **Post update**.

If the problem returns, reopen the incident by moving it to **Monitoring**.

## Publish a postmortem

A postmortem can be written once the incident is resolved.

1. Open the incident and select the **Postmortem** tab.
2. In **What happened, and what changes because of it**, write the analysis.
3. Select **Publish postmortem**. The incident moves to **Postmortem**, and a
   public incident shows the postmortem in the status page history.
4. Under **Action items**, enter each follow-up in **Add an action item** and
   select **Add**. To track one as work, select **Open a ticket** beside it.

To change a published postmortem, edit the text and select **Publish
changes**.

## Use templates

Templates hold the wording nobody wants to compose during an outage. A
template fills a form in and never sends anything by itself.

1. Select **Incidents** > **Templates**, then **New template**.
2. Choose a **Kind**: **Incident**, **Update**, or **Maintenance**.
3. Enter a **Name** your team picks it by, and the **Title** and **Body** it
   fills in. For an incident template, choose a **Default severity**.
4. Select **Save template**.

Incident templates appear in **Start from a template** when you declare an
incident.

## Review incident metrics

Select **Incidents** > **Metrics**, choose **From** and **To**, and select
**Apply**. The page shows **Declared in this range**, **Open right now**,
**Mean time to acknowledge**, and **Mean time to resolve**, broken down **By
severity**, **By month**, and **By component**, and each component's
**Uptime** over the range.

## Next steps

- [Status pages](/service-desk/status-pages/)
- [Tickets](/service-desk/tickets/)
- [Alerts](/service-desk/alerts/)