Template
Incident response automation template
This template starts a response run from an alert. An agent assembles context for the responder, people approve the actions that change things, and the run keeps the timeline.
Last reviewed 7 October 2026
Status
Starting point
The status rests on the governed template incident-response, which the site labels a starting point on its compliance workflow templates page. The gates, the timeline and your runbooks are yours to assemble. The platform does not file regulator reports.
The library has a template, chatflow, MCP server or governed template that covers part of the job. You assemble the rest in Studio.
The job
What this template does
An incident is owned by an incident lead while it lasts, with an on-call engineer doing the work and a communications owner dealing with customers. The first minutes are spent finding things: which alert, which service, what changed, who is on call, where the runbook is.
By hand, that context lives in several heads and tabs, actions go unrecorded and the timeline is rebuilt from chat afterwards. A customer message goes out before the lead has seen it. This flow does the finding and the writing down. People take the actions that change anything, and the run records who approved each one.
Workflow
The workflow, step by step
Steps marked as approval gates pause the run until a named person approves. Nothing after a gate runs before that decision, and the decision is recorded.
- 01
Receive the alert
A monitoring alert or a page starts the run. The workflow opens an incident record with an identifier, the source, the time and the severity as the source reported it. It starts the timeline with that first entry. The next step receives the record. - 02
Assemble context
An agent with read-only access gathers what a responder needs: the runbook for the affected service, recent deployments, related alerts and the last few log lines. It writes a context note with links to each source. Nothing is changed. The responder receives the note. - 03
Notify and open a channel
The workflow pages the on-call person and the incident lead, opens a dedicated chat channel and posts the context note. Every later message from the workflow in that channel is also written to the timeline, with a time, so the record builds as people work. - 04
Approve containment
The agent can propose a containment action, such as rolling back a release or turning off a feature. The run pauses for the incident lead, who approves, changes or refuses it. A person then carries it out and says so in the channel. The decision and the time go onto the timeline.Approval gate: a named person approves before the next step runs. - 05
Approve communications
The agent drafts a status update for affected customers. The run pauses for the communications owner, who edits and approves it before it is sent. Any notice to a regulator goes to the accountable officer instead, and a person files it, because the platform does not.Approval gate: a named person approves before the next step runs. - 06
Close with sign-off
When the responder says service is restored, the run pauses for the incident lead to confirm closure. It then compiles the timeline into a draft review and, once the lead has named the follow-up actions, creates a ticket for each in your tracker, linked back to the incident record.Approval gate: a named person approves before the next step runs.
Controls
What it can do, cannot do, needs approval for, and records
Can
- Start from an alert or a page and open an incident record
- Assemble the runbook, recent changes and logs for the responder
- Notify the on-call person and the incident lead
- Keep a running timeline of actions and decisions
Cannot
- Take containment actions on its own
- Notify customers, the press or authorities
- Alter or delete logs and other evidence
- Decide that an incident is closed
Requires approval
- Containment, by the incident lead
- External communications, by the communications owner
- Notification to a regulator, by the accountable officer
- Closure, by the incident lead
Records
- The alert and the context assembled
- A timeline of each action, approval and time
- Communication drafts and what was sent
- The post-incident review and follow-up tickets
Honest labels
What the library holds for this job
| Asset | Type | Covers | Role in this flow |
|---|---|---|---|
| Incident response | Governed template | Part of the job | Describes the response run: an alert starts it, an agent assembles context, people take the actions that change things and the timeline is the record. It is a starting point, not a finished flow. |
| Technical Troubleshooting Guide | Prompt | Used inside the flow | A starting prompt for turning a runbook into steps a responder can follow. |
| PagerDuty | Integration | Used inside the flow | Pages the on-call person and can start the run. |
| Slack | Integration | Used inside the flow | Hosts the incident channel and carries the approval requests. |
Connections
Integrations this flow uses
- PagerDuty: Pages the on-call person and can start the run.
- Slack: Hosts the incident channel and carries the approval requests.
- Jira: Receives the follow-up tickets.
- Sentry: A possible source of the alert and its error context.
The full list of tools Studio connects to is on the integrations page.
Before you start
What you supply, and what this page does not cover
- You supply the runbooks, the severity scale, the on-call rota, the named approvers for containment and communications, and the contact list.
- The agent has read-only access by design. Give it read access only to logs and deployment history, and nothing that can change a system.
- The platform does not file regulator reports or decide whether you must. Your accountable officer and your counsel do.
- Run it in a drill before you rely on it. A response flow that has never been exercised will surprise you at the worst time.
Common questions
- Will the agent fix the incident?
- No. It gathers context, proposes an action and keeps the record. A person approves and carries out anything that changes a system. That is deliberate: during an incident the cost of a wrong automatic action is higher than the cost of a short pause for the incident lead to say yes.
- What does the starting-point label mean here?
- The site’s governed template for incident response is labelled a starting point. Building blocks exist, such as a pause for a named person and a record of each run, but the gates, the timeline and your runbooks are for you to assemble. No finished incident workflow ships.
- Can it notify a regulator for us?
- No. The flow can alert the accountable officer and hold a draft for them, but a person decides whether a notice is needed and files it. The platform does not file reports. Deadlines and content depend on your jurisdiction and your sector, so take advice.
- Where does the timeline come from?
- From the workflow. Each alert, message, approval and action it handles is written to the incident record with a time. Actions people take outside the channel have to be stated in it, or they will not appear. Agree that rule with your responders in a drill.