Changelog Every update, improvement, and fix. Newest first.
RSS FeedOr get it by email
Channel archiving. The Workspace settings page now lets you choose when Firefight archives an incident's Slack channel after the incident is resolved or cancelled. Pick anything from immediately to 30 days, or choose Never to keep every channel open. The default stays at one hour, and reopening an incident still unarchives its channel.
Consistent tables. Every table in the dashboard now uses the same layout, the sidebar shows the workspace you are in, and a row on the incidents list opens the incident wherever you click it.
Redesigned sign-in pages. The sign-in, install and invite pages have been redesigned around a single form.
Reconnect Slack banner. If Firefight loses access to your Slack workspace, for example because the app was uninstalled, a banner appears on every dashboard page. Admins get a Reconnect Slack button, and everyone else is told to ask an admin. The dashboard keeps working in the meantime.
/ff timeline used to stop after the first few dozen events. It now pages through the whole history, with Older and Newer buttons and a caption showing where you are, such as "Showing events 51 to 95 of 140". A View full timeline button opens the same incident on the dashboard.
Renaming a catalogue attribute used to be able to break paging. Routing now targets a role, not a name. In the type editor, mark an attribute as Members, Manager or Notification channel, and alert routing uses whichever attribute carries that role. Existing workspaces are already marked and route exactly as before.
Missing role warning. If a routing rule depends on a role no attribute carries, a banner says so on Settings and on Alert Routing, and the route tester explains what is missing.
A postmortem is often edited by a person and an agent at the same time. Saving one over the API or MCP now requires the version you edited. If someone changed it in the meantime, the save is refused and nothing is lost.
Dashboard editor. When the dashboard detects that the document changed underneath it, autosave pauses and a banner offers to reload.
API change. version is now required alongside the content when updating a postmortem. A stale version is answered with a conflict, so a client can fetch the latest and try again.
Statuses, severities, incident types, roles, alert sources, webhooks, API keys, agents, catalogue types, custom fields, runbooks, forms, routing rules, permission sets, grants and approval rules can all be created, changed and removed from the REST API and from MCP tools.
Postmortems. Start a postmortem over the API or MCP, optionally with an AI draft, then read it, update it, and set its status. An agent that starts one is recorded as its author.
Routing dry runs. Test a hypothetical alert against your routing rules over the API, the way the route tester does in the dashboard, without creating or notifying anything.
Member attributes. A catalogue member attribute accepts an email or a member id. Someone Firefight does not recognise is refused with a message naming the value, rather than being silently added to the workspace.
The new Agents screen under Gateway is where you create one, issue and revoke its tokens, and disable or re-enable it. Agents act under their own name on the timeline, on action items, and as the author of a postmortem they wrote.
What agents can do during an incident. An agent with the right grants can create, assign and complete action items, claim runbook steps, link related incidents, escalate, invite responders, and give a shoutout, the same things a person does from Slack.
Transcript access. An agent can read what people actually said in the channel only if it holds a separately grantable transcript permission and the workspace has switched transcript access on. That switch is off by default.
Workspace settings. A new Workspace settings screen holds the transcript switch, a retention window after which transcripts are purged (30 days by default), and the archive-channel setting.
The Ability Gateway has its own home. A new Gateway section in the sidebar holds Approvals, Activity and Permissions, with a count of pending approvals on the Approvals link.
Approval rules. Under Permissions you now write approval rules. Each one says which abilities, risk levels and environments it covers, who approves (owners, admins, or named people and agents), where they are asked (the incident channel, a DM to each approver, or both), and whether a requester may approve their own request. Rules run in order and the first match wins. Until you write one, nothing waits.
Slack and the dashboard follow the same rules. Grants and approval rules now govern Slack and the dashboard, not only the API. A Slack action caught by a rule is parked and completes on its own once approved. On the dashboard, a granted ability unlocks the matching controls, and a member without it sees the list without the buttons.
Request source. Activity and Approvals show the source of every request, whether web, Slack, API or MCP.
When an incident resolves or is canceled, Firefight AI reads the conversation and adds those moments to the timeline as notes, each with the quote, who said it, and a link to the message, placed at the time it was said.
Where notes appear. Notes appear in /ff timeline, in /ff catchup, and in the postmortem draft, so the write-up starts from what actually happened. Nothing is posted to Slack.
Dismissing notes. Dismiss any note from the dashboard, and it collapses out of the way. Your own systems can subscribe to the new milestone.noted webhook event.
You can now run an incident from its dashboard page. Resolve, cancel or reopen an incident, update its status or severity, assign the lead and every other role, escalate, invite responders, and give a shoutout, all without switching to Slack.
Same forms as Slack. Every dialog renders the forms you configured, including custom fields, so a status update from the dashboard asks exactly what it asks in Slack.
Timeline entries link to what they mention. Entries now show what they are about. A linked runbook opens the runbook, a related incident links to it, people appear with their avatars, action items appear as cards, and a pinned message shows the quoted text with a link back to Slack. When a runbook attaches automatically, the entry says which condition matched.
Connecting GitHub now takes you straight to the GitHub App install screen, where you pick the repositories Firefight may see. There is nothing to copy or paste, and no token to store.
Code tools for agents. A connected agent can look up a pull request or a commit, fetch a slice of a file with the surrounding lines, search the code, and see who last changed a line and when. Each is a read-only capability you grant like any other.
Secret files are excluded. Files that look like credentials, such as .env files and private keys, are refused outright and filtered from search results.
Automatic health checks. Firefight checks the connection on its own, so the status on the integrations page reflects whether GitHub is reachable right now.
Give one engineer query access to the production database, and an AI agent the ability to file Linear issues, without either being able to touch anything else. The Ability Gateway is how you hand out exactly the access each person and agent needs, watch every use of it, and take it back the moment you want to.
Grants. Developer → Permissions is where access lives. Grant a single ability, such as reading databases in PlanetScale, or a permission set that bundles abilities under a name like Database read-only. Scope any grant to specific environments, so one person reaches only Development while another reaches Production too. A grant can also carry an expiry date and end on its own.
Nothing inherited. Service keys start with no access at all. An agent or script holds exactly the grants you gave it, never the reach of the person who created it. Revoking takes effect immediately.
Approvals. Actions you mark as high risk do not run on a grant alone. They wait in Developer → Approvals, where an admin approves or denies them with full context of who asked and what they asked for.
The activity ledger. Every attempt is recorded in Developer → Activity before it runs, allowed or denied. When something was refused, the ledger shows what was asked and why it did not happen.
Your AI agents can now do real work in Firefight, not just look things up. Ask an agent to update a runbook after an incident, fix who owns a service, or tighten an alert routing rule, and it makes the change itself, with the same permissions and approvals as everyone else.
Twelve write tools. An agent with the right permission can maintain the catalogue (upsert_catalog_entry, delete_catalog_entry), manage alert routing (upsert_routing_rule, delete_routing_rule, update_routing_config), write runbooks (upsert_runbook), attach one to an incident (attach_runbook), shape what responders are asked (upsert_custom_field, upsert_form_field), hand out incident roles (assign_incident_role), and work the approvals queue (approve_approval, deny_approval).
Slugs, not IDs. Everything is addressable by name. An agent can set which team owns a service, or gate a form field on the affected service being checkout, without ever looking up an internal ID.
OAuth for interactive clients. Clients like Claude Code connect with one command and no token handling. The consent screen names the client asking for access and the workspace it would reach, and if you belong to several workspaces you pick one right there. Native desktop clients are supported too.
Governed like everyone else. What an agent may change depends on the credential it connected with. OAuth connections act as you, service keys hold only explicit grants, and every call lands in Developer → Activity.
Incidents get solved in the tools you already run, the code, the dashboards, the tickets, the database. Integrations connect those tools to Firefight, so responders and AI agents can read from them and act in them without leaving the incident. The catalog lives under Configure → Integrations.
What you can connect. GitHub and GitLab for code, Linear for issues, New Relic, Datadog and Grafana for telemetry, Sentry for errors, Notion and Confluence for knowledge, and PlanetScale, Neon, Supabase and PostgreSQL for databases. Anything else that speaks MCP connects as a custom server with a URL.
One click for most. Tools that host their own servers connect with Continue with, an approval on their own consent screen, and nothing to copy or paste. The rest take a URL and a token, stored encrypted and never shown again.
You choose what it can do. Firefight discovers every capability the tool offers, and each enabled capability becomes a permission you can grant to people and agents. Capabilities that change something in the tool are marked write, and Reads only keeps a connection to the safe subset in one move.
A kill switch. The toggle on a connected integration immediately removes its capabilities from everything, including agents connected over MCP, without losing your configuration.
Declaring an incident should take seconds. The dialogs responders fill in now adapt to the incident, so a routine declaration stays short and the important questions still get asked when the stakes are high.
Conditional fields. Any field on a form can carry a condition, and it only appears when the incident matches. Conditions can read the incident type, the severity, and the values of other fields, including catalogue references like the affected service. A "Customer communication owner" field that only appears for your highest severities keeps low-stakes declarations fast while still capturing what matters when it counts.
Live in the dialog. Conditions apply from the moment the dialog opens and re-evaluate as answers change, so responders only ever see the questions that apply to what they are declaring.
Leaner defaults. New workspaces now start with forms that ask only what a new team actually needs. Fields that are always required, like severity and status, cannot be gated behind a condition, so a form can never hide what an incident cannot exist without.
For agents too. get_form shows an agent everything a form holds, hidden fields included, and upsert_form_field changes visibility, requirements, and conditions with the same guardrails as the dashboard.
When something breaks, the first question is who is handling what. You can now assign every role you have defined, like Operations Lead or Communications Lead, during the incident itself, not just the Incident Lead, so anyone joining can see who owns each part of the response.
One dialog for the roster. /ff roles opens a dialog with one picker per role, each showing whoever currently holds it. Change any of them and save, and Firefight posts a single message summarising what changed. /ff lead still works for handing over just the lead.
Visible where it matters. Every assigned role appears in a Roles panel on the incident page, next to the person holding it. Role changes land on the incident timeline with the person named, so looking back you can see who took what and when.
Everywhere else. Role changes reach your own systems as role.assigned and role.unassigned webhook events, and a connected agent can manage the roster with assign_incident_role, under the same rules as in Slack: one person per role, and the lead can be handed over but never left empty.
A procedure only helps if it gets worked. When a runbook attaches to an incident, its steps are now a live checklist the team works through together, right in the channel.
Take a step. The runbook message in the channel lists every step with an I can take this button. Press it and the step becomes an action item assigned to you, and the row turns into Mark as done. Complete it and the row is struck through with your name on it. The message updates in place, so a long procedure never floods the channel.
Hand steps out. View runbook opens the full procedure with a person picker on each step. Assigning a step posts its action in the channel naming the assignee, with the controls to work it right there.
Progress you can see. Each completed step posts a short line naming the runbook it came from, so progress through the procedure is visible without scrolling back. Only steps someone actually takes become actions, so the incident's action list reflects work done, not the whole procedure.
A sharper edge on conditions. A runbook with no conditions no longer attaches to every incident. Attachment now only happens when conditions genuinely match.
Point your monitoring at Firefight and the alerts that matter become incidents, while the noise stays out of your channels. You decide what matters with routing rules, and Firefight handles the repeats, the flapping, and the storms.
Sources. Create an alert source under Settings → Alert Sources and point your tool at its URL. The generic webhook works with Datadog, Grafana, Prometheus Alertmanager, or anything that can POST JSON, with a configurable mapping from the payload to normalized fields like title, service, and severity. Northflank has a dedicated integration.
Routing rules. Rules run in order and the first match wins. Each pairs conditions on the alert's fields with one of four outcomes: create an incident, attach to an open incident, notify a channel or person without an incident, or drop. Alerts that match nothing are stored as unmatched and stay visible, so you can see what fell through and tighten your rules.
The catalogue fills in the blanks. An alert carrying only service: checkout is enriched before routing. The owning team is merged in from the catalogue, and entry attributes become fields like service.tier, so a rule can route by metadata the alert itself never sent.
Built for noisy nights. Repeat firings update the existing alert instead of creating new ones, a flap window catches alerts that resolve and immediately re-fire, and a grouping window attaches related alerts to the incident already open for the problem. One bad deploy that fires fifty alerts becomes one incident with fifty attached alerts, and one Slack digest message that updates in place.
Dry runs. Test a hypothetical alert against your real rules from Settings → Alert Routing before pointing production at it, and see the per-condition trace of what matched. Connected agents get the same thing through evaluate_routing, which never creates or notifies.
Your team's "here's what to do when this breaks" knowledge now lives in Firefight, and shows up exactly when it applies.
Structured procedures. A runbook has a summary, a rich procedure written in a formatting editor and stored as Markdown, an optional external link, and an ordered list of steps. Manage them at Settings → Runbooks.
Automatic attachment. Conditions decide which incidents a runbook applies to: incident type, severity, and custom fields, including catalog references like the affected service. Conditions are evaluated at declaration and re-evaluated on every update, so a runbook scoped to a service attaches the moment that field is set.
From checklist to actions. Attached runbooks post into the incident channel with their steps and an Add steps as actions button. One press creates an action item per step, assignable and trackable like any other.
Built for AI agents. Attached runbooks are part of the incident context Firefight's AI sees, and connected agents can browse them over MCP with two new read-only tools, search_runbooks and get_runbook. The REST API exposes the same data at GET /api/v1/runbooks under a new runbooks permission resource.
On the record. New runbook.attached and runbook.applied timeline events, both available to outbound webhooks.
Run the entire incident from Slack. Declare with /firefight and FireFight sets up the incident and its channel for you.
From there you can:
FireFight manages the incident channel through the whole lifecycle: created when you declare, kept current as things change, and archived on close.
FireFight puts AI on the busywork around an incident:
The AI layer is model-agnostic, so you're not tied to a single provider.
You don't stop firefighting to log what happened. React to a message and FireFight captures it:
The timeline builds itself out of how your team already communicates.
Slack is where you run incidents. The dashboard is where you understand them.
Configure FireFight to match how your team works:
Bring incidents in from the rest of your stack. The REST API at /api/v1 covers:
source so you know where each one came fromAuthentication is Bearer-token via API keys with per-resource permissions, and incident creation is idempotent, so retries never create duplicates.
Subscribe your own services to incident events. Deliveries are signed and timestamped, and failed deliveries are retried automatically, with delivery tracking so you can see exactly what was sent and when.
Every incident has a dedicated page in the dashboard showing its timeline, its actions and follow-ups, and its postmortem, alongside the activity happening in Slack.
Files and screenshots shared in the incident channel are rendered inline in the incident timeline, so the visual context of what happened stays with the record.
If you belong to more than one workspace running FireFight, you can switch between them from a single account without signing out.
FireFight is open source under AGPL-3.0. Self-host it on your own infrastructure, keep your incident data inside your own perimeter, and point the AI layer at your own model. Because the codebase is open, your security team can read exactly what it does instead of taking our word for it.