Incident conversations

Firefight stores what people say in an incident channel so it can summarise the incident, note what was worked out onto the timeline, and draft a postmortem from it. Two settings under Settings → Workspace decide who else can read those messages and how long they are kept.

Both settings are admin-only. They sit on the workspace rather than on a permission, because turning access on is a decision about your data rather than a decision about one person.

Letting agents read the conversation

Let AI agents read incident conversations is off when you start. While it is off, nothing outside Firefight’s own AI features can read the messages, and a request for them is refused whoever makes it, admins included.

Turning it on does not by itself let anyone read anything. A caller also needs the Incident Transcripts ability, which is granted like any other under Permissions. Both have to be true, so an agent you granted every incident ability still reads nothing until you turn this on, and turning it on gives nothing to an agent you never granted the ability.

Caution

The transcript is the rawest data in your workspace. Secrets matching known token formats are redacted before anything is stored, and each message says whether it was, but names, customer details and links are not. See AI data handling for exactly what is scanned.

Reading it

There is no transcript viewer on the dashboard. The conversation is already in Slack, where you can scroll it, so this is for agents and scripts that need the reasoning behind a timeline rather than the timeline itself.

Over MCP, get_incident_transcript takes the incident and returns its messages oldest last, each with who said it, when, the text, and whether anything in it was redacted. Over REST it is GET /api/v1/incidents/:id/transcript, which returns the same thing.

Both return 100 messages by default and 500 at most. A long conversation comes back from the end, since the end is usually the part worth reading, and each response carries a more_before cursor. Pass it back as before to walk further into the past. When there is nothing older left, more_before comes back empty.

curl "https://app.firefight.app/api/v1/incidents/3f8c1a90-2b7e-4d15-9c04-6ea5b3d71f28/transcript?limit=50" \
  -H "Authorization: Bearer ff_4kWm2xPqR8vNcT6yBhJd3fLzGaU9sEnQoXwA"

With the setting off, both surfaces refuse and say so, rather than returning an empty conversation that would read as a quiet incident.

How long conversations are kept

Keep conversations for takes a number of days counted from when the incident ends, and defaults to 30. Leave it empty to keep conversations for good.

The clock starts when the incident is resolved or canceled rather than when it was declared, so a long incident keeps its whole conversation while it runs and for the full window afterwards. Postmortems are usually written the morning after, and generating one reads the conversation, so a window of a few days is enough for that.

Clearing the messages does not clear what the team worked out. That survives on the incident’s timeline, where each note carries the quote and the person behind it, and in the postmortem where one was written. What you lose is the conversation around those moments.

Changing the number applies from the next day’s purge onward. Shortening the window is not reversible, since the messages it covers are deleted rather than hidden.