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
Section titled “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
Section titled “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
Section titled “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.
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
Section titled “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.