Introducing FireFight, Open-source incident management, built for Slack

The outage is only half the problem

It's 5pm on a Friday. Half the team is already thinking about the weekend. Then checkout starts throwing 500s, and the support inbox fills up with people who can't pay.

You find out because someone tags you in a thread that's already sixty messages deep. You scroll up and try to reconstruct it. Three conversations are tangled together in there. Someone is debugging, someone else is asking a question that got answered forty messages ago, and a third person has spun up another channel you can't find. Nobody has written down what's been tried or ruled out. You still don't know who's leading this, or whether it's yours.

Then it goes quiet, which is somehow worse. Is it fixed, or did everyone assume someone else had it? Nobody says either way. It's Saturday morning before someone tags you again, asking for an update you don't have.

Eventually the service comes back. But it's not over. There's a postmortem to write, customers to tell what happened, and lessons to turn into fixes. And every bit of it starts by reconstructing the story from scratch, out of six scrolled-past threads, with half of it already forgotten.

That's the problem. Not the outage. The chaos around the outage.

FireFight fixes that. And it's open source.

What FireFight is

FireFight is incident management that lives inside Slack. Declare an incident from anywhere, and the confusion turns into structure. A severity, a status, an owner, and a timeline that writes itself. When the incident closes, you're editing the postmortem, not writing it from scratch.

No new tab. No separate tool your team forgets to open. It's live today, and you can self-host it.

We made it open source. On purpose.

FireFight is AGPL-3.0. The whole thing is on GitHub, and it's not a stripped-down version with the good parts held back.

That matters even if you never run it yourself. Incident data is some of the most sensitive you have, and your security team can read exactly what touches it instead of taking our word for it. If your requirements change, you can take it and run it on your own infrastructure with your own model.

Most teams would still rather not manage infrastructure for their incident tool, which is what Cloud is for. We handle the hosting and the upgrades. The difference is you're choosing us, not stuck with us.

Run the whole incident in Slack

You never leave Slack. There's nothing new to learn, because it's the tool you're already living in during an outage. Declare with /firefight and FireFight creates the incident and its channel for you. From there you can do all of this.

• Set severity, status, and type inline, and keep the summary current
• Assign a lead, or take it yourself from the pinned actions at the top of the channel
• Pull in responders, and escalate when it's stuck. They get a DM with an Acknowledge button, plus a nudge if it goes unanswered
• Say when the next update is due, and get reminded when it is
• Link related incidents, or mark one a duplicate and merge it
• Close it, or reopen it if it comes back

FireFight runs the incident channel for you. It's created when you declare, the topic shows the current severity, status and lead, and it's archived once you close.

Public incidents are also announced in a shared #incidents channel, and that post stays current as things change. Anyone who wants to keep an eye on things can follow along there without joining the incident channel itself. Private incidents skip the announcement and get a private channel instead, same command and same flow.

The timeline writes itself

You don't stop firefighting to log what happened. Everything that happens to the incident is already on the record. Every status and severity change with what it was before, who took the lead, who got escalated to and whether they acknowledged, the files people shared, the alerts that fired, and the moment it was resolved. Each entry is stamped with who did it and when.

When something in the chat matters, pin it and it lands on the timeline too, or react to it to turn it into a tracked action item, a follow-up, or a shoutout.

By the time the incident is over, the record is already there. Nobody has to reconstruct anything.

AI that does the work, on your terms

FireFight uses AI where it saves you time and nowhere it shouldn't.

• Catch me up summarizes the incident for anyone who just joined, so you stop re-explaining
• Postmortems are generated from the timeline you built, then you edit them
• Live summaries keep the current state accurate without anyone maintaining it

It's model-agnostic, so you're not locked to one vendor.

See everything outside the channel

Slack is where you run incidents. The dashboard is where you understand them.

• A filterable incident list with stats and MTTR
• A full timeline and audit trail of every state change
• A service catalogue, custom fields, and configurable forms and roles

Connect it to what you already run

FireFight fits into your stack instead of asking you to rebuild around it.

• A public REST API to create and manage incidents from your own tools
• An alert endpoint your monitoring posts to, with rules that decide whether an alert opens an incident, joins one that's already open, or just notifies someone
• Outbound webhooks with automatic retries

Rules can work out who to pull in from your catalogue, so an alert about a service reaches the team that owns it. Repeat firings collapse into one alert instead of a wall of them, and a storm becomes one incident. You can test a rule against a sample before you trust it.

Where this goes next

We're building toward something bigger. A system that any responder, human or AI agent, acts through safely, with a real record of what happened and real limits on what can be done. That's the roadmap, not today's release. But everything above is the foundation it's built on, and all of it works right now.

Build it with us

FireFight is open source, and we're building it in public. The roadmap, the issues, the rough edges are all out in the open. Follow along, tell us what's missing, and help build it.

Get started

Sign in and declare your first incident in under a minute.

Or clone the repo and run it on your own infrastructure. Either way, the next outage doesn't have to be chaos.