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.
Closed and Canceled both mean the response is over, so the incident channel’s Resolve, Escalate and Make me Lead buttons go away once an incident reaches either one.
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.
Cancelling is its own action rather than just another status change. Use /ff cancel, or the Cancel incident button that sits next to Accept incident while an incident is still in triage. A cancelled incident keeps its channel and timeline, but it never counts as resolved, so it stays out of your time-to-resolve figures and is not offered a postmortem. If you cancel something and then find out it was real, reopen it with /ff reopen and carry on in the same channel.
If you add a second status to the Closed or Canceled stage, responders are asked which one applies when they resolve or cancel. That is the simplest way to record why something was cancelled. Add “Duplicate” and “False positive” alongside “Canceled” and every cancellation says which it was, with no extra field to fill in. While a stage holds a single status there is nothing to choose, so nobody is asked.
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.
The timeline
Section titled “The timeline”Every incident page in the dashboard has a timeline: the full story of what happened, in order, with who did it and what it was about. Each entry names its subject rather than just the kind of thing that happened.
- Status, severity, lead, and field changes show the before and after, one row per field. When the summary is rewritten, the card shows the new text. Click Show previous version to read what it replaced.
- Runbooks name the runbook, and the name opens it. A runbook that attached itself also says which rule matched, such as “Severity is one of Critical, Major”.
- Action items show the item’s description, its status, and who holds it. Clicking one highlights it in the Actions panel.
- Escalations name the person, with their avatar, and the reason given. Reminders and acknowledgements sit alongside.
- Pinned messages quote the message and link to it in Slack.
- Alerts name the alert that attached or resolved. Related, duplicate, and merged incidents name the other incident and link to it.
- Roles name the role and the person.
Entries performed by a person carry their avatar. Entries Firefight performed on its own, such as attaching a runbook by rule or sending an escalation reminder, are attributed to Firefight.
On the incidents list, click anywhere on a row to open the incident. The ID and name are links as well, so an incident declared without a name is still one click away.
The incident page is also where you change any of this. See Running an incident from the dashboard.
Timeline notes
Section titled “Timeline notes”The timeline above records what Firefight did. It does not record what the team worked out. The theory someone floated at 14:20 and the rollback that finally worked live in the channel, and they go with it. When an incident is resolved or cancelled, Firefight reads the channel once and adds the milestones of the investigation to the timeline as notes.
A note is one line in the past tense, attributed to the person who said it and placed at the time they said it, so it sits inside the conversation and reads alongside the rest of the timeline. Each one is labelled AI-noted, quotes the message it came from, and links straight to that message in Slack.
Firefight notes eight kinds of moment.
| Kind | Example |
|---|---|
| Hypothesis | Diego suspected the 14:02 deploy |
| Finding | Uros confirmed the connection pool was exhausted on replica 2 |
| Root cause | Diego identified the migration lock as the root cause |
| Mitigation | Uros rolled back the 14:02 deploy |
| Decision | The team decided to fail over rather than wait for the vendor |
| Blocker | The team was blocked on Datadog support with no ETA |
| Impact | Checkout was down for EU customers only |
| Recovery | Error rate returned to baseline |
Greetings, acknowledgements, unanswered questions, and anything already on the timeline are left out. Status changes and escalations are recorded as events in their own right, so a note never repeats one.
Nothing is posted to the channel. Notes appear on the incident’s timeline in the dashboard, and they flow into the postmortem draft, /ff catchup on a closed incident, the API, and anything reading your timeline over MCP, so an agent can ask what the root cause of a past incident was without reading a single message.
Dismissing a note
Section titled “Dismissing a note”A note is a reading of a conversation, and a reading can be wrong. If one credits the wrong person or takes a joke for a decision, open the note’s actions menu on the timeline and choose Dismiss note.
Dismissed notes are not deleted. They collect at the end of their day on the timeline under “N dismissed notes”, which you can expand to see what was dismissed and by whom, so the correction stays visible. Everywhere else a dismissed note is gone. It leaves the API, MCP, /ff catchup, and any postmortem drafted afterwards.
An incident is read once, however long it ran and however many messages it holds. See AI in Firefight for what the AI sees and AI data handling for what is stored and redacted.
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.