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