---
title: "Statuses, severities & types"
description: "The four concepts Firefight uses to describe every incident."
canonical: https://firefight.app/docs/incidents/concepts/
---

# Statuses, severities & types

Every incident in Firefight carries four pieces of classification. Two of them, **status** and **severity**, change over the incident's life. The other two, **type** and the underlying **lifecycle stage**, describe what kind of thing it is and where it stands. Understanding how they fit together makes everything else in Firefight predictable.

## Lifecycle stages

Under the hood, every incident is in exactly one of four stages.

| Stage | Meaning |
|---|---|
| **Triage** | Something's been reported, but it's not yet confirmed as a real incident. |
| **Active** | A confirmed incident with an ongoing response. |
| **Closed** | The incident is over and was real. |
| **Canceled** | It turned out not to be an incident. A false positive or duplicate. |

You can't add or rename stages, and you'll rarely deal with them directly. They exist to give your statuses meaning. Every status maps to one stage, so no matter how you customize the labels, Firefight always knows which incidents are live, which are closed, and which never turned out to be real.

## Statuses

Statuses are the labels your team actually moves incidents through, and each status belongs to one of the stages above. A new workspace starts with these.

| Status | Stage | Typically means |
|---|---|---|
| Triaging | Triage | Confirming whether this is a real incident |
| Investigating | Active | Root cause under active investigation |
| Identified | Active | Root cause found, fix in progress |
| Monitoring | Active | Fix deployed, watching for stability |
| Resolved | Closed | Fully resolved |
| Canceled | Canceled | False positive, duplicate, or invalid |

You change status with `/ff status` or `/ff update` in the incident channel, and each change is announced and recorded on the timeline. Because each status maps to a stage, moving an incident from Monitoring to Resolved is also what closes it. There's no separate bookkeeping step.

Statuses are fully customizable in **Settings → Statuses**. Rename them, reorder them, add your own within any stage, and choose which one new incidents start in.

## Severities

Severity says how bad the incident is, independent of where it is in its lifecycle.

| Severity | Typically means |
|---|---|
| **Critical** | Service-wide outage or data loss |
| **Major** | Significant feature degradation |
| **Minor** | Limited impact or a workaround exists |

Severity is set when the incident is declared and can be changed at any time with `/ff severity` as you learn more. It's normal for an incident to be declared Minor and upgraded once the blast radius is clear. Severity drives visibility. It appears in announcements, channel headers, and dashboard filters, and alert routing rules can set it automatically for incidents created from alerts.

Customize the list and its order in **Settings → Severities**.

## Types

Type answers "what kind of incident is this?" and is useful for filtering and for spotting patterns across incidents. The defaults are **Production**, **Security**, **Infrastructure**, **Data**, and **Third Party**.

Type is chosen at declare time and is mostly an organizational tool. Reviewing last quarter's incidents by type tells you where your reliability effort should go. Customize in **Settings → Types**.

## How they work together

A typical incident reads like this. Someone declares a **Production** incident at **Major** severity, and it starts in the **Investigating** status. When the scope becomes clear, severity is raised to **Critical**. The response moves from **Investigating** to **Identified**, then to **Monitoring**, and ends at **Resolved**, which also closes the incident.

A practical rule of thumb is that **status describes the response and severity describes the impact**. If you need a label for waiting on a vendor, add a status. If you need a label for a full outage, add a severity.