Incident Response

Overview

When an alert lands in a configured Slack channel, an Incident Response automation automatically starts a linked Droid session so Droid can investigate the incident with the right context, machine, and instructions.

Droid can work toward an RCA, open a PR for a fix when appropriate, and update an incident runbook so future investigations of the same alert type start faster.

Quickstart: set up from the Factory App

Incident Response is set up as an automation in the Factory App.

1. 1
   Invite Factory to the incident channel

   In Slack, open the channel where alert bots post incidents and run:

   /invite @Factory

   If you have not connected Slack yet, set up the Slack integration first. Only channels where Factory has been invited appear in the channel picker.

2. 2
   Create a new automation

   In the Factory App, open All Automations under Software Factory in the sidebar and click New automation.

3. 3
   Choose the Incident Response template

   From the template gallery, select the Incident Response template under Software Factory templates.

   

4. 4
   Name the automation and select trigger channels

   Give the automation a name, then under Triggers, search for and select the incident channel. Trigger on messages from defaults to Bots only, which matches alert bots posting incidents; change it only if humans should also trigger investigations.

   

5. 5
   Choose Account and Computer

   • Run as sets the identity and billing the automation runs under. A service account is recommended for incident response so the computer and session interactivity are shared across the team.
   • Run on sets the computer where Droid investigates. Pick the computer with the right repositories, observability tools, and anything else you want to add that can help the agent. Learn more about Droid Computers.
6. 6
   Configure MCP servers

   Use Configure MCP Servers to add and authenticate the observability tools and context sources Droid needs to respond to incidents. MCP servers are configured per computer and require connection to the computer to set up; if you have issues, retry a few times or change the computer.

7. 7
   Review the prompt and model

   The template pre-fills a prompt that is injected into every session triggered from the channel:

   Use the `/incident` skill for Slack incidents and run an RCA if applicable.
   If the thread message is an incident or asking for RCA/root-cause analysis, invoke the `incident` skill before investigating.

   Keep the default or add channel-specific instructions, and optionally select a model.

8. 8
   Set session privacy and create

   Choose whether triggered sessions are visible to your Team or Private, review any Additional Settings, then click Create.

9. 9
   Send a test alert

   Post a test top-level alert from the same kind of bot that will send real incidents. Confirm the automation starts a Droid session and links it from the Slack thread. You can review runs from the automation's detail view.

Configuration details

Customizing the prompt

The automation prompt is injected into every session triggered from the channel. Keep it specific to incident work:

• Tell Droid to run RCA and use the /incident workflow when appropriate.
• Mention the primary services or repositories for that channel.
• Point Droid at runbooks, dashboards, or common alert sources.
• State escalation expectations, such as when to summarize uncertainty instead of taking action.

Avoid prompts that make the automation a general-purpose Slack surface. Incident Response works best when the prompt is narrow and operational. For broader Slack workflows, create a separate Slack automation instead.

Channel selection and trigger source

Incident Response is designed for channels where incident alerts arrive as top-level messages. Thread replies are not used to start new sessions, which prevents ordinary discussion from repeatedly launching Droids.

For best results, use a dedicated channel such as #incidents, #alerts-production, or a service-specific incident channel.

The channel picker only shows channels where Factory has been invited. Trigger on messages from defaults to Bots only so ordinary messages in the channel do not trigger investigations; widen it only if humans should also be able to start incident sessions.

Session privacy and model

Session privacy controls who can see triggered sessions. Private sessions are visible to the run identity. Team sessions can be reviewed by other members, which is useful for incident handoff and postmortem review.

Use the default model unless your team has a known preference for incident analysis. For complex production incidents, choose a stronger reasoning model if available.

Managing the automation

Open the automation from All Automations to see recent runs and statuses. Depending on your permissions, you can run now, pause, resume, share, fork, rename, edit, or delete the automation. Pause the automation instead of deleting it when you want to temporarily stop incident sessions.

How the incident flow works

Once configured, Incident Response follows this flow:

1. 1
   An alert bot posts a top-level message in the configured Slack channel.
2. 2
   The automation starts a Droid session using its run identity, computer, session privacy, model, and prompt.
3. 3
   Droid receives the Slack alert context and checks for any matching incident-guidelines runbook guidance.
4. 4
   Droid investigates with the configured tools and should invoke the /incident workflow when RCA is appropriate.
5. 5
   Factory posts status and session links back into Slack, and Droid can save reusable learnings for similar incidents.

The incident-guidelines runbook is stored locally at .factory/skills/incident-guidelines/SKILL.md for team reuse or ~/.factory/skills/incident-guidelines/SKILL.md for personal reuse. It should store reusable investigation guidance, not secrets or one-off RCA details.

Troubleshooting