What's new in FireFight

DeepSeek V4.1 Flash now takes V4 Flash's place in the model menu, for accounts on DeepSeek and on OpenRouter. Chats and AI accounts that used V4 Flash moved to V4.1 Flash, so there is nothing to change. See Choosing the model.

Ask Halon to tell you when something finishes, and it can now follow far more of what you run. See Halon watching for you.

More runs. Deployments on GitHub, GitLab and Bitbucket by environment name, Azure DevOps and CircleCI runs, Render cron runs, one-off jobs and workflow tasks, Railway cron runs, Lambda deploys, ACR Tasks runs, Cloudflare Workers builds, Trigger.dev deployments, DigitalOcean job runs, Upstash Workflow runs, PlanetScale deploy requests and Supabase preview branch runs.

Waiting for a person. A deploy waiting for approval or a manual job shows as waiting, never as queued, in one line such as production waiting for someone to approve or start it, and is never called slower than usual.

Live updates you turn on. Turn on Azure's instant updates through Event Grid, and a change reaches the map within about a minute. Turn on a Convex log stream and its changes reach the map within about a minute. Send Cloudflare's Pages notification or Trigger.dev's alerts to Firefight, and Halon hears at once. PlanetScale now adds its own webhooks, and DigitalOcean, ClickHouse and Modal are checked every 5 minutes. See Live updates.

Rollbacks on code hosts. On GitHub, GitLab and Bitbucket, name a deployment from a repository's recent deploys and Halon runs again what made it, on that deployment's commit. See Code hosts and CI.

More on GitLab and GitHub. Halon reads each repository's deployment environments and what holds a deploy to them, reruns one GitHub job, and retries, starts or cancels a GitLab job, approves a GitLab deployment and stops an environment. Bitbucket runs a pipeline on one commit and shows a step's test reports.

CircleCI. CircleCI now connects with a personal API token. Halon follows runs job by job, reads logs, tests and what each project deployed, and reruns, cancels, approves a held job, runs a pipeline or rolls back. Firefight adds a webhook to each project so a watch hears at once. Connecting through CircleCI's own server still works. See CircleCI.

You can now connect Azure DevOps on the Integrations page under Configure, in the Code group. Paste a personal access token, type your organization and pick the projects it reads. See Azure DevOps.

What Halon reads. Repositories, pull requests and code, pipelines and their runs with each stage and job and its log, the approvals a run waits on, what each environment received and classic release deployments. Repositories and pipelines show on the resource map.

What Halon does. Run a pipeline, rerun a run's failed jobs, cancel a run, approve or reject an approval, and roll back by deploying an earlier deployment again. Each asks you first.

Live updates. With a token from a project administrator, Firefight adds service hooks so a push reaches the map and a watch hears of each stage, job and approval as it moves.

Halon can now change your databases when you allow it, and every change asks you first. See Changes to databases.

Neon. Restore a branch to a moment, keeping its current state as a branch of its own, resize a compute, and start one Neon has suspended. Halon reads a branch's slowest queries and a project's consumption as charts.

ClickHouse. Scale a service's replicas and memory, start, wake or stop a service, and read the organization's activity log and a service's backups. ClickPipes show on the map, and a service's state reaches the map within about 6 minutes.

Turso and Upstash. Roll a Turso database back by making a new database from a moment, and read its usage. Restore an Upstash Redis database from a backup, pause a QStash schedule for a while, and resume failed Workflow runs or deliver dead letters again.

PlanetScale and Supabase. Cancel, cut over, apply, complete or revert PlanetScale deploy requests, resize a branch, and promote or demote one. Restart a Supabase project, restore it to a moment, and read its health, metrics, backups and preview branch runs.

PostgreSQL. Halon reads rollbacks, deadlocks and the queries that take the most time.

Connecting with a key. ClickHouse, Neon, Turso and Upstash take their API key in plain fields under Use a token instead, and PlanetScale has a Service token ID you can add from the connection later. See Connect an integration.

Halon can now make many more changes where your apps run, when you allow them. Each one asks you first unless it is a safe change, and anything that stops what someone else started asks them too. See Changes on each platform.

Fly.io. Start, stop or suspend an app's machines, cordon one machine out of traffic, add or remove machines, and give them another size or amount of memory. Halon also reads a Managed Postgres cluster's costliest queries and the ones running now.

Vercel and Netlify. Cancel a deployment that is still building, or build one again. On Vercel, Halon charts a project's requests, errors and function time, reads Vercel CI runs, and moves a rolling release to its next stage, completes it or stops it. On Netlify, it locks auto publishing after a rollback and unlocks it once the fix ships.

Render and Railway. Deploy again, cancel a deploy, suspend and resume, run a cron job now, run a one-off job or a workflow task, and change autoscaling on Render, where Halon can also turn autodeploy off so a rollback holds. On Railway, redeploy, cancel, stop or approve a deployment, scale one region at a time, and read request traces and cron runs, in any environment of the project.

DigitalOcean and Trigger.dev. Keep or undo a DigitalOcean rollback, cancel a deployment, an autoscaling or a job run, and redeploy. On Trigger.dev, cancel or replay runs one at a time or in bulk, pause and resume queues, change their concurrency, and mark error groups resolved or ignored.

Cloudflare, Convex and Modal. Retry a Pages deployment, cancel a Workers build or split a Worker's traffic between two versions. Pause or unpause a Convex deployment and read its usage beside its limits. Stop a Modal app or one of its containers.

AWS and Azure. Reboot an EC2 instance or an RDS database, roll a Lambda function back with any canary split taken off, and read ACR Tasks runs. On Azure, Halon reads which settings differ between a deployment slot and production, and follows a slot swap until it ends.

You can now give Halon your own skills under Halon → Skills. A skill is a short recipe for a task: when it applies, the tools it needs, and numbered steps. Halon loads it only when a question fits. See Skills.

Writing one. Choose New skill and fill in its name, when Halon uses it, its tools and its steps. Every save is a new version, and History lets you bring back an earlier one. A skill never widens anyone's access, and one that looks like it holds a password or key is refused.

Copying Firefight's. Copy on one of Firefight's skills makes Halon use your copy instead. When Firefight ships a newer version you are told, and you choose Take Firefight's version or Keep mine.

Proposed by Halon. Ask Halon in a chat to save what it just did as a skill, or work out a better way to do something a skill covers, and it proposes one. Nothing changes until someone accepts it, from the chat, from Slack or on the Skills page.

Adding and changing skills needs the Skills permission, which admins have and can grant. Agents can read and change skills over MCP and the API.

You can now build workflows. Open Workflows under Halon in the dashboard. A workflow is a set of steps Firefight runs for you, such as "every weekday at 9:00, look through the logs for probing and raise a notice if there is any". Each workflow acts as its own identity, never as the person who made it, and can do only what it was granted when it was published. See Workflows.

Triggers. A workflow starts by hand, on a schedule, once at a time you pick, or when something happens: an incident declared or changed, an alert, a notice from Halon, a finished investigation, a follow up or postmortem, a deploy or CI run, a change on the resource map, a service scaling, a security event, an issue assigned to Firefight or labelled in GitHub, GitLab or Linear, another workflow's failed run, or a signed POST to its own address.

Steps. Call any tool Firefight or a connected integration offers, ask Halon, investigate, classify, open or update an incident, post an update, page on call, create a follow up, post to a channel, message a person, update your status page, run a command or a script in a sandbox, check an address from outside, open a page in Halon's browser, send an HTTP request or a webhook, ask a person, ask for approval, hand someone a manual step, branch, wait, watch, loop and run another workflow.

The canvas. Every workflow opens on a canvas, where you add and connect steps, try a draft with Test run, pin a step's output, and follow each run step by step with Try again, Skip and Start again from here. Ask Halon beside the canvas changes the workflow for you as suggestions you accept or dismiss. See Building a workflow on the canvas.

From a chat. Ask Halon to do something later or on a repeat, and it shows the workflow it would make and makes it once you confirm.

The library. The Library tab holds checks Firefight ships and keeps up to date, such as a disk space check and a certificate check, to use as they are or copy. Export a workflow as a file and import it into another workspace. See Workflow library.

Runbooks. A runbook can link a workflow, and its Run it button starts it. See Runbooks.

Limits and settings. Each workflow has a spending ceiling per run, a most runs per hour, an owning team that hears about failed runs, and what to do when a change lands in a freeze window. Members make, test and run workflows. Publishing and settings are an admin's. Agents can list, create and run workflows over MCP, and change a workflow's settings over the API.

On Firefight's cloud, your plan now includes AI every month, the trial too. Halon spends it on Firefight's own AI account once none of your own AI accounts can pay, and before any Firefight credits you bought. See Included AI.

See what is left. The Firefight credits row under your AI accounts, the Billing settings screen and setup's Choose Halon's AI step show how much of this month's included AI is used and left, and when it renews.

Told before it runs out. Admins get an email and a Slack message when most of the month's included AI is used, and again when it runs out. Halon then carries on with your credits, and pauses only when there is nothing left to pay with, saying what ran out and when the included AI renews.

An open incident page now keeps itself up to date. A lead assigned in Slack, a status set over the API, an action Halon adds or an alert that joins the incident shows up on the page as it happens, without a refresh. See Running an incident from the dashboard.

Only the part of the page that changed is read again, so a dialog you are typing in stays as it is. The page updates only for people who may read the incident, and a burst of changes, such as an alert storm, arrives as at most one update a second.

Firefight's incident messages in Slack are now compact cards that read at a glance.

The announcement. An incident in your incidents channel is one card with its title, its severity and status on one line, and its summary, followed by Join channel, Subscribe and Open in Firefight, and who declared it underneath.

The pinned message. The incident channel's pinned message says the same on one line, with the summary and the quick actions under it, rather than listing every field on its own.

Every update. Status and severity changes, written updates, escalations, resolving and reopening each post as a card that names what changed, such as the severity moving from one level to another, with the update's own words as its body and who wrote it underneath.

Subscribers. Someone following an incident gets one short card per update in their direct messages, naming the incident and what happened, with Open channel, Open in Firefight and Unsubscribe. See Running an incident from the dashboard.

Halon's replies. When a mention starts an investigation or adds to one, its eyes reaction turns into a check as soon as the run has it, so you can tell it was picked up.

A Slack workspace that cannot show cards gets the same content as plain messages.

Every change Halon wants to make now asks on one short card, in the dashboard and in Slack alike, such as Halon wants to: restart web, with one line under it and Approve, Cancel and Details. Details shows exactly what it will send. See What Halon can do.

Approving runs it. When an approval rule needs someone else to approve a change Halon wants to make in a chat, approving it runs the change straight away, as the person who asked Halon, and Halon tells the chat how it went.

Asked where people are. The request is posted in the chat's Slack thread, so the people in the conversation see it, and its approvers are asked wherever the approval rule says. A new Default choice for where a rule asks, which new rules start on, sends a direct message to each approver and keeps the request out of the shared incidents channel. Rules saved before keep asking where they did.

Followed to the end. Once answered, the request says who decided and follows the change until it says it is done, failed or was cancelled. See Approvals.

Anyone in the channel can now follow an investigation without opening anything. See Following it in Slack.

A live checklist. The run's first message, such as Investigating INC-42, lists what Halon has looked at so far, such as Checked recent deploys and Read the code, each marked waiting, working, done or failed. It updates in place and says Investigated INC-42 once Halon is done.

A short answer in the channel. The answer goes to the channel in a few plain lines, what kind of answer it is and how sure Halon is, what is wrong in one sentence, up to three facts behind it and the suggested fix, with Apply fix and Open in Firefight. The full answer follows in the thread.

Fixes Firefight runs itself. A fix step that any of Firefight's own tools can do, such as inviting someone to the channel, assigning a role, paging or posting an update, now runs through Firefight as whoever applied the fix, so it is never left to you. A step whose change is already in place is marked done and says why, and each step that went through shows what it produced with its link, such as Opened a pull request: PR #856.

One message per fix. Applying a fix posts a single checklist, such as Fix for INC-003, that updates as each step moves and ends with Fix applied or Fix stopped. A step that fails says why in plain words and offers Try again. The fix also shows on the incident's timeline, with who applied it and each step's result.

Atlassian Statuspage and Instatus now connect under Status pages on the Integrations page, each with an API key. Firefight lists your pages with the key before it saves anything, so a wrong key is refused on the form. See Connect a status page.

What Halon reads. Your pages, components, open and past incidents with every update, maintenance, subscribers and metrics. Name a page or a component by its name, so you can ask Halon to set "Checkout" to a major outage without looking up an id. Every answer links to the page as your customers see it.

What Halon can change. Open an incident and post updates, schedule maintenance, set a component's status, write and publish a postmortem on Statuspage, manage subscribers, and the rest of what each provider's API offers. Every change is seen by your customers, so each one needs a grant, follows your approval rules and asks before it runs in a chat. A tool that would notify subscribers asks whether to tell them, with no default. Halon never changes a status page while it investigates.

Secrets stay in the provider. Settings that work as passwords, such as a monitor's credentials or a page's SMS provider, are never sent or shown, so set those in the provider itself.

Post to a channel. Ask Halon to post a message as Firefight in any channel it can post in, such as release notes in #general or a heads up to a team's channel. The post names who asked for it, Halon confirms it with you first, and approval rules apply. Agents use post_to_channel. A private channel needs Firefight invited first.

Outbound webhooks. Agents create, change and delete outbound webhooks with upsert_outbound_webhook and delete_outbound_webhook, and test_outbound_webhook sends a test delivery, signed like a live one, by replaying the newest event the webhook subscribes to.

Member access. list_member_access reads what members can read and change in each connected tool, as the Permissions screen shows it, and set_member_access sets one of them to everyone, nobody, or chosen people.

Paths Halon may not change. update_protected_paths adds or removes paths in a code host connection's repositories that Halon's code changes may never touch, the same list admins edit on the connection.

Integrations. list_integrations lists what can be connected and what already is, by kind of tool.

See MCP server for every tool.

Grafana Cloud. Connect a Grafana Cloud stack by signing in, one stack at a time, with nothing to paste. Type the stack's address, choose Continue with Grafana, and leave write and query access off on Grafana's screen so Firefight can only read. When a stack has more than one Loki, Prometheus or Tempo datasource, choose which one holds the logs, metrics and traces Halon reads. A Grafana you run yourself still connects with its server's address. See Grafana.

GitHub. Halon can now edit and publish releases, revert a pull request, review a deployment that waits for approval, and clear Actions caches, and read a repository's access, Actions variables and build artifacts. Every change asks first and follows your approval rules.

Northflank templates. Halon can read, follow, start and abort the runs of your Northflank team's templates, and templates show on the resource map.

SigNoz regions. SigNoz Cloud connects in its US2, EU2 and India 2 regions too.

Linear now connects through Firefight's own Linear app, with Continue with Linear and a Linear admin's approval, and nothing to copy. Every tool Linear offers arrives on the connection, and the app works in Linear as Firefight, so issues and comments it makes show as Firefight and keep working when the person who connected it leaves. See Linear.

Halon in the issue. Assign an issue to Firefight, or mention Firefight in a comment, and Halon answers in the issue after reading it and its comments. A follow-up comment carries on the same conversation.

Changes still ask. Halon there acts as Firefight's own agent, with only what an admin granted it. When it wants to make a change, it lists the change in the issue with Confirm and Skip, and only a member whose email matches the Linear account that picks counts. A change an approval rule holds runs once someone approves it, and Halon says in the issue how it went.

Issue sync without setup. With the app connected, issue tracking registers Linear's webhook itself, so changes made in Linear reach Firefight with nothing to paste. Jira has its own app for issue sync too.

Halon can now keep an eye on something after it answers. Ask it in a chat to tell you when a run finishes, or when a deploy starts and succeeds, and it checks about every minute until everything it follows is done, something fails or its time runs out. See Halon watching for you.

In your own words. Say "tell me when run #46 finishes, and when the web deploy succeeds", or "keep checking web until every instance runs the new version". Halon finds each thing on the resource map, says how long it will watch from how long these runs usually take, and offers to watch whenever you start something that takes a while.

Only what matters. In the dashboard each watch is one card that updates in place, with a row per thing it follows and Open the run. A failed job is reported at once, with why from its own log, and a closing line says how it ended. Each line also reaches you as a direct message in Slack, or in the chat's Slack thread.

Only reads. A watch checks as you, with your permissions, never changes anything, and keeps to a ceiling on how often it reads each provider. Stop it from the card, from Stop on any update in Slack, or by telling Halon. Agents list and stop watches with list_watches and stop_watch over MCP.

You now decide which AI Halon runs on. See AI accounts.

Your own accounts. Admins add one or more accounts under AI accounts on the Workspace settings screen, from Anthropic, OpenAI, Google Gemini, OpenRouter, Amazon Bedrock, Google Vertex AI, Azure AI Foundry, DeepSeek, Mistral or xAI, and on a Firefight you run yourself Ollama and GPUStack too. Firefight checks each key with one short call when you save it. Halon tries the accounts from the top of the list, and an account that runs out of credit is skipped until a check passes again, with each admin told once in Slack.

Main and quick models. Each account has a main model for chats and investigations and a cheaper quick model for side jobs such as summaries, both filled in with the models Firefight recommends for that provider. See AI models.

A backup when a provider stops answering. Halon carries on from the same step with the account's backup model, then the next account, and says so in one line where its steps are shown.

Pick the model for a chat. The message box shows which model Halon answers with. Choose another your provider serves, each described in a few words, and the chat uses it from your next question. Each answer names the model that wrote it.

Or Firefight's AI. On Firefight's cloud, Halon can run on Firefight's own AI account instead, so you need no key. Admins buy Firefight credits from the Billing settings screen or during setup, and credits never expire.

Alert sources now read the webhooks of the tools you already alert from, with no field mapping to write. See How alerts work.

New sources. Sentry, Datadog, Grafana, Prometheus Alertmanager, New Relic, Honeycomb, Axiom, Better Stack, Honeybadger, OpenStatus, SigNoz, Logfire, PostHog, Mixpanel, PagerDuty and Opsgenie join Northflank and the generic webhook.

Setup in the dialog. Creating a source opens the steps for that tool, with what to copy into it. Most tools send a token, Sentry signs its requests with a secret you paste in, and Logfire gets an address with the secret built into it, shown in full only to people who can change alert sources.

Batches, resolving and links. Grafana, Alertmanager and SigNoz batches become one alert each, and an alert resolves when the tool says so. When a tool sends a link to the alert, its title in Slack, on the incident page and on the Alerts page opens that page in the tool.

Resolve by hand. Someone who manages alerts can now resolve a firing alert from the Alerts page.

Halon can now take the first look at an alert when nobody is awake to. Everything is set on the new On-call page under Halon, which admins can open, and each setting is off until you turn it on. See Halon on call.

Start Halon when an alert opens an incident. Every incident an alert opens gets an investigation as soon as its channel is ready. Alerts that group into one incident start Halon once, and a spending ceiling per hour covers a storm of alerts that do not group.

Page whoever is on call. At the end of such an investigation, Halon pages the person on call for what broke, with its answer and the fix it proposes. With PagerDuty connected it raises an incident on the right service, and with Opsgenie an alert for the right team or schedule, so the tool's own escalation wakes them. Without an on-call tool, Halon escalates the incident in Firefight instead. You can also ask Halon to page someone during an incident, and agents use page_on_call.

Pages stay in step, both ways. Resolving the incident in Firefight resolves its open pages, and acknowledging an escalation acknowledges them. Acknowledging, escalating or adding a note in PagerDuty or Opsgenie shows on the incident's timeline, and the incident page's Pages panel lists every page and where it stands.

Unattended rules. Decide ahead which changes Halon may make on its own after an alert, such as "Restart checkout when its 5xx responses over the last 10 minutes average above 50". Halon acts only when every change in the fix matches a rule, it holds the permission, and a fresh reading is above the threshold, and then it posts what it did and how to undo it. Agents manage rules with upsert_unattended_rule, list_unattended_rules and delete_unattended_rule.

Halon now has a sandbox of its own, with a terminal and a real browser, in chats and in investigations. It starts the first time Halon needs it.

Terminal. Halon runs shell commands and scripts when one tool call is not enough, such as counting the errors in a large log or grouping a hundred CI runs by the test that failed. Scripts can call your connected tools through Firefight, as the person who asked, and kubectl and the Northflank command line work against your connections. Each command shows as a Run command step. See Halon's terminal.

Checks from outside. Halon can check an address the way a user reaches it, with its DNS records, how long each part of the request took, and its certificate and how many days are left on it.

Browser. For questions about what people see, such as "the checkout button does nothing", Halon opens the page in Chromium on a desktop and a phone screen, follows the steps a person would take, and reports the status, timings, console errors, failed requests and a screenshot. For pages behind a login, an admin saves a test account on the Test logins page under Halon. See Halon's browser.

Your keys stay out, changes ask first. The sandbox holds no key, token or password of yours, since every call goes through Firefight, which adds the key itself and records the call. A command that changes something asks you first. In the browser, looking around never asks, and a step that would send data, such as submitting a form, stops and shows you exactly what it would send before anything leaves.

Some changes need more than a yes, so Firefight now adds a safeguard around them, shown on the confirmation before you approve. See Halon's safe changes.

Changes to rows. Before an UPDATE, DELETE or INSERT through a connected database, Firefight counts the rows it would touch and shows a few of them. Right before it runs, it counts again and stops if the number moved, then keeps a copy of the rows as they were, which you can download for 30 days.

Temporary changes. A change your customers feel for a while, such as turning a feature flag off, adding a Cloudflare block or pausing a service, is undone after an hour by default. Pick another time or Never under Undo automatically. Firefight reminds you before the time is up, with Keep it, One more hour and Undo now.

Someone else's run. Before Halon cancels a CI run someone else started, that person is asked in Slack with Agree and Say no, and the run is cancelled only once they agree.

When something breaks, the first questions are what changed, whether a provider you depend on is down, and whether the answer sits in a system Firefight cannot see. Halon now answers all three before it guesses. See What changed, provider status and blind spots.

What changed. One list, newest first, of everything that changed around a resource, a service or the whole workspace, from the map, live updates, changes made through Firefight, and the provider's own builds, deploys and CI runs. It is in each resource's panel on the map and on the incident page, where Read runs now reads the provider's runs as you.

Provider status. When logs or errors show failures calling a provider's address, such as timeouts to a payment API, Halon reads that provider's public status page straight away and says whether it reports an outage, before blaming your own code. Agents use check_status_page.

Blind spots. When a question needs a system you have not connected, such as an outside sign-in provider, Halon names it, says where it saw your apps use it, and links to connect it instead of guessing. Agents list these with blind_spots.

Halon can now look at your systems without anyone asking. Everything lives on the new Monitoring page under Halon. See Monitoring and security.

Scheduled checks. Add a check for disk space, certificates, error budget, cost, or something else you describe in your own words, and run it every day or every week at the hour you choose. Each run reads your connected tools, works out the trend over days or weeks, and says the day something becomes a problem. Run now starts one at once.

Said once, to the right team. Each problem is posted once in the channel of the team that owns it, marked Worth knowing, Needs doing within weeks or Needs doing now, and again only if it gets worse. A problem with no owner, such as your cloud bill, goes to the monitoring channel you choose. What Halon raised lists every problem with when it was last said.

Cost. A cost check reads spend from AWS, Azure, DigitalOcean, PlanetScale, Vercel, Northflank, GitHub, Trigger.dev and Cloudflare, against the months before, with what grew.

Leaked secrets. When GitHub's secret scanning finds a secret in a connected repository, Halon works out what it reaches, reads what was done with it and proposes how to revoke and replace it, in the owning team's channel. Every change it proposes waits for a person.

Every member sees the page, and changing checks needs the Monitoring permission. Agents read what Halon raised with list_notices over MCP.

Ask Halon for something that takes more than one step, such as a release or a fix across two systems, and it now writes a short plan first and keeps it up to date while it works. See Halon's plans.

A checklist you can watch. The plan shows your goal in your words and one step per action, each naming where it happens, in the chat and in the Slack thread you asked from. A step that changes something shows how to put it back before it runs. Each change still asks you as usual, and approval rules still apply.

Checked, then reported. A plan that changes something ends by reading how what it touched stands now, against its usual error rate and latency, and says Worked, Did not work or Could not check. Halon then reports against your goal with links to the run or the deploy. If a step fails, the plan stops and offers Retry and Undo.

Helpers. When a question needs several reads that do not depend on each other, such as the logs, the recent deploys and the error rate of one service, Halon hands them to helpers that read at the same time and report back in a few lines. Helpers only read, with the same permissions as whoever Halon is working for. See Helpers.

The new Handbook under Halon is where your team writes down how the workspace works, such as how you release, who owns what, what counts as production and when changes are frozen. Halon reads it at the start of every chat and investigation, follows it, and links the page it followed in its answer. See The handbook.

Three ways to start. Draft with Halon reads your resource map, repositories and past incidents and proposes a page for each thing a new teammate would need to know. Import docs brings in a file or folder from a connected repository, or a page from Notion, and keeps it in step with its source. Write a page starts blank or from a common starting page.

Every edit kept. History shows each earlier wording with who wrote it. Short pages are read whole, and a long page is searched when Halon needs it.

Halon proposes edits. When something Halon reads contradicts a page, such as releases running through a different pipeline than the page says, it works from what it read and proposes an edit, with Accept edit, Edit first and Dismiss. Proposals also wait in the handbook under Waiting for review.

Who directs Halon. When two people in an incident ask Halon for opposite things, it says so and follows the person in the role the handbook names, the Incident Lead unless you choose another.

Writing the handbook needs the handbook permission, and everyone can read it. Pages can also be managed over the API and with the list_handbook_pages, get_handbook_page, upsert_handbook_page and delete_handbook_page MCP tools.

A new workspace now starts with a short setup checklist, right after the welcome letter, that gets Halon ready to work on your stack. Owners and admins go through it, and teammates who join meanwhile go straight to the dashboard. See Setting up your workspace.

The steps. Choose how Halon gets its AI, connect your tools one kind at a time (cloud and hosting, observability, code and the rest), read how access works and give someone a pack if they need one, ask Halon a first question in Chat, connect Slack, and run a test incident.

Kind by kind. Each kind of tool says in a sentence what Halon can do with it, and Connect opens the same dialog as the Integrations page. Kinds your team does not use take We don't use this, except code, where your apps run and what watches them, which Halon needs.

Leave and come back. Setup keeps every answer and opens where you stopped, on any device. Every step confirms itself, and the dashboard opens once the last one is done.

A new Performance page under Halon shows how its investigations have gone for your workspace, over the last 7, 30 or 90 days. Every member can open it, and every number comes from what your team recorded. Nothing on it is estimated. See Performance.

Answers. How many answers your team rated right, out of those rated, how many investigations reached an answer, the median time to answer, and a weekly chart of right, partly right, wrong and not rated.

Fixes. How many fixes Halon proposed, and how many were applied, undone or cancelled.

Where Halon was wrong. Up to ten answers your team marked wrong, with what Halon said and the lessons it learned from each.

Agents read the same numbers with get_halon_performance over MCP, and you can ask Halon in a chat how it has been doing.

Halon now keeps short facts about your setup, such as which database is production or which service handles payments, so the next chat or investigation starts from what your team already knows. See Halon's memory.

Where memories come from. Halon keeps at most three lessons when an incident ends, reads a completed postmortem for anything new, and saves lasting facts it works out while answering. Ask it to remember something in a chat, or add one yourself on the Memory page under Halon. It never keeps a secret, a reading that will have changed by the next incident, or anything about a person.

Hunches, not proof. A memory nobody confirmed is a hunch Halon checks against live results, and it says so when it relies on one. When a new fact contradicts an old one, the old memory becomes Disputed and Halon asks which is right, with Still right, Not right and Correct.

Your team decides. The incident's channel gets one message with what Halon learned, each memory with Confirm, Not right and Correct. The Memory page lists everything, flags a memory whose resource changed since, and lets you correct or delete any of them.

Instructions. On the Instructions tab of the Memory page, tell Halon how your team wants it to work, such as where to look first or what never to touch, for the whole workspace, one team, one service or one resource on the map. Halon follows them in every chat and investigation that touches that place. See Instructions for Halon.

Every answer that names a cause now comes with a fix, a short summary with ordered steps, how to undo each one and how to tell it worked. Nothing runs until a person applies it. See Fixes.

Kinds of step. A step is a code change opened as a pull request, a change through one of your connected tools with exactly what it sends shown beside it, or a step for a person that names who does what and where. A step that waits on others says so and runs only once they are done.

Apply fix. Choose Apply fix in Slack or in the dashboard. The steps run in order, as you and with your permissions, and each shows where it got to. A step an approval rule holds waits for its approver. A step for a person shows Done to press once you have done it.

Code changes as pull requests. A coding agent writes the change in a sandbox, it is checked and reviewed against what was asked, and the pull request opens through your code host connection. Merging stays a person's decision. An admin can hand code changes to Devin, Cursor or Factory instead, and can list paths in each repository that Halon may never change. Halon follows every pull request it opens and tells you when one conflicts, fails a check or gets a review asking for changes, with Fix it.

Cancel and undo. Cancel fix stops the steps that have not run yet. Undo fix has Halon write the steps that put back what was changed, from what each step actually did, for you to apply like any fix.

An investigation is Halon working out on its own why something is broken. It writes down its theories, tests them against your systems, and ends with an answer, the evidence behind it and a fix you can apply. See Investigations.

Starting one. Run /ff investigate in an incident channel, choose Investigate on the incident's pinned message or on its page in the dashboard, mention @Firefight with a message that starts with investigate, or ask in a chat. Agents use start_investigation and get_investigation over MCP.

Before there is an incident. In any other channel, say what is wrong, such as /ff investigate checkout returns 500 since 14:00. When the answer says users are hurt now, it offers Declare incident, and the new incident starts with what Halon found.

How it works. Halon starts from the earliest real sign of trouble and the clues in the alerts and what people said. It checks where the incident's services run on the resource map and what changed there, ranks the code changes that landed before the trouble, and reads the code itself in a sandbox of its own, at the commit that was running. Before an answer goes out, Halon is asked to prove itself wrong, and every claim is checked against what the steps it cites actually returned.

Follow along. The run's thread in Slack shows each step as it happens, and the dashboard shows the whole run, its theories marked Open, Supported or Ruled out, and every step with what it returned. The incident's timeline shows when each run started and answered. Mention @Firefight in a running investigation's thread, or use Tell Halon something in the dashboard, to add what you know without starting again. Stop ends a run after the step it is on.

Only reads. An investigation runs as Firefight Investigator, with only what you grant it under Gateway, and never changes anything in your systems. A fix it proposes waits for a person.

Rate the answer. Every answer ends with Right, Partly right and Wrong. Halon learns from answers marked wrong, and the next run that meets the same alert reads the past answers your team rated.

Halon is Firefight's AI SRE, now on for every workspace. Ask it a question or ask it to do something, and it does the work the question needs before it answers, reading Firefight's own records and your connected tools and naming where each claim came from. See Halon.

Where you meet it. Open Chat under Halon in the dashboard sidebar, or mention @Firefight in an active incident's channel and Halon answers in the thread. Agents connected over MCP ask it with ask_halon. Every member can ask Halon without a grant, and an admin can take that away.

Acts as you. In a chat Halon works with exactly your permissions, so it never sees or changes more than you could. Reads go ahead without asking. A change waits for you to confirm it on a card, and approval rules still apply. Every call it makes is in Activity under Gateway.

Watch it work. Each step shows as it runs, such as Search logs · Production (Northflank), and folds away once the answer arrives. Keep typing while it works to steer it, or choose Stop to end the answer.

More than text. Metrics Halon reads are drawn as charts, in the dashboard and in Slack, with a link to the live chart where the provider has one. Attach a screenshot, a PDF or a log and Halon reads it as evidence. When a question needs a tool you have not connected, it shows the integrations of that kind with Connect.

Knows your providers. Halon reads each connected provider's own documentation, kept fresh every day, follows short skills Firefight writes for common tasks with each tool, and can search the web for a library's docs unless an admin turns that off.

See Chatting with Halon for everything the chat does.

Providers that split an account into projects now let one connection read as many of them as you like. This covers Northflank, Railway and Google Cloud projects, Azure subscriptions, Render and Bitbucket workspaces, and Vercel teams. See Choosing what a connection reads.

Pick from a list. Paste the token, then open Projects and Firefight lists what that token can read. Pick one, several, or All this token can read, which also takes in a project created later. Change the choice any time from the connection.

Kept apart. The map keeps each project's resources separate, so two services called web are two services, each named with its project. A restart, a scale or a log search reaches only the project the resource lives in, and confirmations, approvals and Activity name the project a call reaches.

Connections made before this keep reading the one project they were connected with.

Connecting a tool now makes it useful to your whole team straight away. See Permissions.

Reads by default. Every member can use the capabilities of a connected tool that only read, such as a log search or a deploy list, without a grant. An admin can still take that away for someone. Agents and service keys still hold nothing until you grant it.

Changes come in packs. Each connection brings its own built-in packs, one for its reads and one for its changes, such as Northflank: changes. Give someone the changes pack and they can use everything on that connection that changes something, with your approval rules still applying. Firefight keeps the built-in packs in step as tools come and go.

New tools arrive switched on. A newly connected tool, and a capability a tool adds later, arrive switched on, reads and changes alike. Being switched on is not permission, and anything you switch off stays off for everyone.

Ask an admin. When Halon is refused a change for want of a pack, it names the pack and your admins, with Ask an admin. Pressing it sends each admin a direct message in Slack with Give pack, and the request waits at the top of the Permissions screen under Waiting for a pack. Each admin hears about a pack from you at most once a day.

The resource map no longer waits for its next scheduled read. Most connections now tell Firefight when something changes, or keep a log of changes Firefight reads every few minutes, and the map reads that resource again straight away.

Live updates. Vercel, Render, Railway, Northflank, Netlify, GitHub, GitLab, Bitbucket, PlanetScale and Supabase send changes by webhook, which reach the map within about a minute. AWS, Google Cloud, Azure, Cloudflare, Fly.io, Neon and Kubernetes are checked every few minutes. Each connection under Integrations, and the Live updates section beside the map, says whether live updates are on and when the last change arrived, or why they are off.

What changed. The panel beside the map lists what changed in the last 24 hours, such as a deploy, a status that moved, a setting that changed, or something new or gone.

Key checks. Open a resource in Focus to see the first readings worth taking on it, such as a service's error rate and p95 latency, each with what is normal for it over the last week. Run takes the reading now and says how it compares, such as "Now 412 ms, 3.1x the usual high of 133 ms".

Usual log lines. Firefight learns the kinds of line each important resource usually logs, so a line seen during an incident can be told apart from one that was there all week. Only the patterns are kept, never the lines.

An incident's actions and follow-ups can now live in Linear or Jira too. Change an item's title, status or assignee in Firefight and its issue follows, and a change made to the issue comes back to the item. Set it up in the Issue tracking card on the Workspace settings screen. See Issue tracking.

When an item gets an issue. Choose Never, Only when someone asks, Always for follow-ups or Always for actions and follow-ups. It applies however the item was added, from Slack, the dashboard, the API, an agent over MCP or Halon.

Create issue. Unless the setting is Never, an item without an issue offers Create issue on the incident page and on its message in the incident channel. Agents use create_action_item_issue. The issue carries the item's title, the incident's identifier and a link back to the incident.

Both ways. Picking up, handing over, completing, reopening and renaming an item move the issue to match. Completing, reopening, reassigning or renaming the issue in the tracker does the same to the item, and the channel hears when it is done. People are matched by email.

More you can do with an item. Rename, reopen and unassign are now in each item's menu on the incident page, on its message in Slack, and over the API and MCP (rename_action_item, reopen_action_item, unassign_action_item).

Recorded. Every change made either way is in Activity under Gateway, with the source Issue sync.

The Integrations page now covers the whole stack an incident runs through, grouped by what each provider is. See Connect an integration.

Cloud and hosting. AWS, Google Cloud, Azure, Kubernetes, Cloudflare, Northflank, Vercel, Render, Railway, Fly.io, DigitalOcean, Netlify, Convex, Trigger.dev and Modal. Each puts what it runs on the resource map.

Observability. Honeycomb, Axiom, Better Stack, Logfire, OpenStatus, Honeybadger and SigNoz join Datadog, Grafana, New Relic and Sentry. Datadog now connects in any of its regions.

Databases. ClickHouse, Tinybird, Turso and Upstash join Neon, Supabase and PlanetScale, and PostgreSQL connects straight from a connection URL, read only.

CI, on-call and issues. Bitbucket and CircleCI for builds, PagerDuty and Opsgenie for who is on call and what is paging, and Jira for issues.

Product analytics. PostHog and Mixpanel, to see who an incident reaches, what they did and which feature flag changed.

Coding agents. Devin, Cursor and Factory, which can write the code change in a fix and open the pull request.

The same questions everywhere. For any resource on the map, you can ask for its logs, metrics, deploys and status, and roll it back, restart it or scale it where the provider allows, the same way whichever provider runs it. Every change needs a grant and follows your approval rules.

New colours. The dashboard uses the same near-black and lime palette as the Firefight website. Workspaces still on the default severity, status, incident type and catalog type colours move to the new ones automatically, and any colour you picked yourself stays as it is.

Readable badges. Severity badges show one to three filled signal bars, and every status badge carries an icon, a distinct one for each default status, so you can tell them apart at a glance without relying on colour.

A new Map page, under Respond in the sidebar, shows what your connected providers run and how each piece depends on the others. Every connection to a provider that runs or holds infrastructure puts what it reaches on the map, each resource linked to its page on the provider. See The map.

Three views. Map draws each account as a box, arranged in the direction things depend, with anything that has an open incident outlined in red. Focus shows one resource and everything up to three links away, following what it needs, what needs it, or both. Table ranks every resource by how many others depend on it, and can show only the ones with no links yet.

Every link says how it was found. A link is either reported by the provider, matched from a setting such as DATABASE_URL that names the database's exact address, added by a person, or suggested by Firefight from clues like matching names. Suggestions, such as which service uses which database, are drawn dashed and wait under To review until someone confirms or dismisses them. A setting's value is read in memory only and never stored.

Linked to the catalog. Link a resource to the catalog service it runs, and an incident that names that service lights the resource up on the map and counts toward its history.

Search everything at once. Press Ctrl K, or ⌘K on a Mac, on any dashboard page to search the map and the catalog together, by name, tag, owning team or what a service does.

Who sees it. Reading the map is its own permission. Every member sees the whole map by default, and an admin can limit someone to some environments. Agents read it once granted, with MCP tools such as get_resource_map, search_map, find_resources, blast_radius and suggest_resource_link.

You can now change the workspace settings from a connected agent. update_workspace_settings turns incident transcript access on or off, sets how many days transcripts are kept, and sets how long after an incident ends its channel is archived. Give only the settings you want to change, and read the current values with get_workspace_config, which now includes them.

Admins only. The tool needs the workspace permission, the same one the settings page needs, and it cannot be granted to an agent or a service key.

Halon asks first. When Halon makes one of these changes in a chat, it asks you to confirm before it goes ahead, since they apply to the whole workspace.

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.

Read more: How alerts work · Alert deduplication & grouping

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:

• Set severity and status inline
• Assign a lead and pull in responders
• Escalate when it's stuck, and acknowledge when someone picks it up
• Close it, or reopen it if it comes back

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:

• Postmortems are drafted from the timeline, then you edit them
• Catch me up summarizes the incident for anyone who just joined
• Live summaries keep the current state accurate without anyone maintaining it

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:

• Turn a message into a tracked action item
• Capture a follow-up for after the incident is over
• Give a teammate a shoutout in the moment they earned 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.

• Filter incidents by severity, status and search
• See stats including MTTR across your workspace
• Open any incident for its full timeline and audit trail

Configure FireFight to match how your team works:

• A service catalogue with typed attributes and relationships between entries
• Custom fields on incidents
• Configurable incident forms, types and roles

Bring incidents in from the rest of your stack. The REST API at /api/v1 covers:

• Creating and updating incidents, with a source so you know where each one came from
• Reading severities, statuses and incident types
• Reading and writing the catalogue

Authentication 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.