> ## Documentation Index > Fetch the complete documentation index at: https://docs.komodor.com/llms.txt > Use this file to discover all available pages before exploring further. # Incidents in Slack > Start an incident from Slack, follow it in its thread, stop it, and ask about it. KAOP checks each action against your own permissions. The Komodor Agentic Operation Platform (KAOP) runs incident workflows from Slack. You start an incident by mentioning KAOP's Slack app, follow and steer it in the same thread, and ask about it there once it is done. Nothing has to be set up in the channel. What you do from Slack (starting, stopping, pressing a button, asking) is checked against your own KAOP permissions; the investigation itself runs with the workflow's own agents. ## Before you start * **Slack is connected** to your KAOP account, through KAOP's Slack app or your own Slack app connected for chat. Both work the same way. See [Connecting Slack](https://docs.komodor.com/manage-your-agents/run/channels.md#connecting-slack). If you connected your own Slack app for chat, mention that app wherever this page says KAOP's Slack app. * **The app is in the channel.** * **At least one incident workflow is active.** See [Incident management & troubleshooting](https://docs.komodor.com/modules-and-workflows/sre/incidents.md). * **Your Slack account is linked to your KAOP user.** The first time you start, stop or ask about an incident, KAOP replies with a connect prompt that only you can see. That request is not kept: once you have linked, mention the app again. A Stop pressed before you linked can stay on Stopping…, so stop the incident from its incident page instead. Slack Connect guests from another organization cannot act on incidents. Each action needs a KAOP permission, checked as you: | To | You need permission to | Roles that have it by default | | - | - | - | | Start an incident | Manage that workflow | Owner, Admin, Developer, Operator | | Stop, continue, resolve or retry an incident | Manage incidents | Owner, Admin, Developer, Operator | | Ask about an incident | View incidents and use chat | Owner, Admin, Developer, Operator, Member | Roles and custom grants are described in [Roles & permissions](https://docs.komodor.com/security-and-governance/identity-and-access/roles-permissions.md). ## Start an incident **1. Mention the app with incident** In a channel or a thread, mention KAOP's Slack app, then `incident`, then what's wrong: `incident checkout-api returns 500s since the 10:30 deploy`. `incident` must be the first word after the mention. Under an alert another app posted, such as Datadog or Grafana, reply in the alert's thread with the mention and `incident` alone: the alert says what's wrong. **2. Check the start card** KAOP reacts with 👀 and posts a card only you can see: **Start an incident?** It names the workflow KAOP picked and why, and under an alert it also shows the alert's labels and severity. The dropdown lists the active workflows you can start, so you can pick another. **3. Press Start** Nothing is created until you press **Start**. **Cancel** removes the card. If you edit your message before pressing Start, KAOP uses the edited text. KAOP picks the workflow in this order: 1. The only workflow you can start. 2. Under an alert, the workflow whose alert source is the app that posted it. 3. The workflow last started in this channel. If none applies, the dropdown starts empty and you choose. ### Starting under an alert An incident started under an alert takes the alert's title, severity and labels, so a workflow's filter on those fields sees what the alert says. Labels are the alert's `key:value` tokens, such as `env:prod`. Your own words become the incident's description. ### When KAOP does not start a new incident | What happened | What KAOP replies | | - | - | | This thread already has an incident from that workflow | 🔁 **Already handled:** who started it and when, with **Open incident**. Under an alert, KAOP checks this before showing the card. A different workflow in the same thread starts a second incident; Stop and questions in that thread then go to the newest incident, so manage the other one from its incident page. | | The workflow's filter skips the alert | 🚫 **Filtered out:** the condition that failed, with **Open the workflow** | | The workflow is paused, or has reached its hourly incident limit | ⏸️ **Not started:** with **Open the workflow** | | You cannot start that workflow | Only you see: "You can't start *workflow*. Starting one needs permission to manage it in KAOP. Ask an admin." | | There is no workflow you can start | Only you see why: no incident workflows are set up yet, or none you may start | | You wrote in a direct message | A pointer to start it from a channel | | You wrote only `incident`, outside an alert's thread | Only you see a hint to say what's wrong after `incident` | ## Follow it in the thread The incident reports in the thread you started it from, with one short reply at each milestone: when it starts, when it finds a likely cause, when the agent has a question, when a fix is applied, and when it ends. If an agent's tool call needs approval, its approval card is posted in the thread as well. An incident opened by an alert routed to a workflow reports in the alert's thread the same way. **The reaction on your message** shows where it stands, one at a time: 👀 picked up, ⏳ working, ✅ resolved, ❌ failed or stopped, 🟡 needs review. **Slack's own status** under the thread shows KAOP working while the investigation runs, with Slack's Stop button beside it. It clears while the incident waits for a person and when it ends. | Reply | When | | - | - | | 🚀 **Started:** *workflow* is investigating *incident*, with **Started by** and **Open incident** | The investigation starts | | 🔍 **Likely cause:** with a collapsed **What I checked** list | The investigation finds a likely cause | | 🙋 **The agent has a question** | The agent needs a decision. It tags whoever started the incident and offers **Select** on each option. Once someone picks, the card reads ☑️ **Answered by** and the choice. | | 🛠️ **Fixed:** what was done. Waiting for the alert to clear. | A fix was applied | | ✅ **Resolved in** *time*: with the bottom line, also shown in the channel the thread is in | The incident resolves, from the thread, the incident page or the co-pilot | | ❌ **Investigation failed:** the cause, with **Continue** and **Resolve** | A step failed and can be continued | | ⏹️ **Stopped by** *person* during *step*, with **Continue** and **Resolve** | Someone pressed Stop | | 🟡 **Needs review:** the reason, with **Resolve** | It stopped and there is nothing left to continue | | ⏸️ **Not investigated:** | The workflow has used its investigation budget | | ❌ **Couldn't start:** with **Retry** | The workflow failed to start | If the workflow also notifies a Slack channel, that channel gets the full summary when the workflow reaches its conclusion. When it is the channel the incident was started in, the conclusion is posted once, in the thread. A resolve by a person, from the thread, the incident page or the co-pilot, reaches the incident's thread only, not the workflow's notification channel. ### Continue, Resolve and Retry **Continue** picks the investigation up from the step that stopped, **Retry** starts a workflow that failed to start again, and **Resolve** closes the incident. A button acts as the person who presses it: it needs a linked Slack account and permission to manage incidents, and anyone else gets a private refusal. Once pressed, the buttons give way to **Continued by**, **Retried by** or **Resolved by** and the person's name. If two people press at once, only one press goes through. Every press is recorded in the audit log under the person's name. ## Stop it While KAOP is working, press Slack's Stop button under the thread. KAOP stops the running step and posts ⏹️ **Stopped by** you, with **Continue** and **Resolve**, so the incident can pick up again later. The incident's timeline records who asked to stop it. Anyone with permission to manage incidents can stop one, not only the person who started it. Only the person who pressed Stop sees these replies: | What happened | What KAOP replies | | - | - | | You lack permission to manage incidents | “You can't stop this incident. Stopping needs permission to manage incidents in KAOP.” The Stop button stays usable for someone who can. | | Nothing is running | “Nothing is running on this incident right now, so there was nothing to stop.” | | The stop did not go through | “Couldn't stop it. Try again, or stop it from the incident page.” with **Open incident** | | Your Slack account is not linked | The connect prompt. Link, then stop the incident from its incident page. | ## Ask about it Mention KAOP's Slack app with your question in the incident's thread, for example `what was the likely cause?`. The answer is posted in the thread and comes from that incident: its alert, findings and runs, and the incident's chat. It ends with **From incident** and the incident's name, linked, beside a link to the run that answered. Asking never changes the incident's findings or status. The question runs as you, so you need a linked Slack account and permission to view incidents and use chat. If the answer needs a tool call approved, the approval card appears in the thread. | What happened | What KAOP replies | | - | - | | The investigation is still running | “⏳ Still investigating: on *step*. I'll answer questions about the outcome when it finishes.” | | You lack permission | Only you see: "You can't ask about this incident. Asking needs permission to view incidents and chat in KAOP. Ask an admin." | | You mentioned the app with no question | Only you see a hint to ask in the same message | A reply in the thread that does not mention the app gets no answer. **Slack and the incident page share one conversation.** A question asked in Slack shows in the incident's **Ask about this incident** card, labelled with the asker's name and **via Slack** (yours reads **You · via Slack**), and in Chat. A question asked on the incident page is not posted to Slack. The answer in Slack is public to the channel and can draw on the whole incident chat, including questions asked on the page. ## Next steps > [card] [Channels](https://docs.komodor.com/manage-your-agents/run/channels.md) > > Connect Slack, and route alerts from other apps to an incident workflow. > [card] [Incident management & troubleshooting](https://docs.komodor.com/modules-and-workflows/sre/incidents.md) > > Set up the incident workflows you start from Slack. > [card] [Roles & permissions](https://docs.komodor.com/security-and-governance/identity-and-access/roles-permissions.md) > > Who can start, stop and ask about incidents. > [card] [Your own Slack app](https://docs.komodor.com/manage-your-agents/run/slack-own-app.md) > > Run incidents in Slack through an app you own. ## Related topics - [Channels](https://docs.komodor.com/manage-your-agents/run/channels.md) - [What's new](https://docs.komodor.com/reference/changelog.md) - [Incident management & troubleshooting](https://docs.komodor.com/modules-and-workflows/sre/incidents.md) - [Onboarding](https://docs.komodor.com/get-started/onboarding.md) - [MCP server](https://docs.komodor.com/developer-tools/mcp-server.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.