> ## Documentation Index
> Fetch the complete documentation index at: https://docs.traversal.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Incident Workers
> A proactive AI SRE that works your incident channel from the first signal through verified recovery.
An **Incident Worker** joins your incident channel the moment it opens, starts investigating, and stays with the team until recovery is verified. It follows the whole conversation, adapts as evidence changes, and decides for itself when to speak and when to stay out of the way.
Because it starts before anyone has to ask, responders walk into a channel where the first round of investigation is often already done. This is the default incident experience.
## What it does
An Incident Worker isn't running a checklist. It reads what the incident needs and works on that, the way an engineer on the call would — and you can always just ask it for something instead, in the channel or in private chat.
Most often that means:
* **Investigating** — the channel context plus the relevant telemetry, code, deployments, tickets, and knowledge.
* **Assessing impact** — which services, users, and regions are affected, kept current as things move.
* **Testing theories** — chasing new clues, ruling out weak paths, and correcting its own earlier conclusions when the evidence turns.
* **Weighing in on mitigation** — showing the evidence behind a proposed action, including when the action on the table would make things worse.
* **Verifying recovery** — confirming against live signals that the incident is really over, not just that a fix shipped.
* **Drafting the post-mortem** — turning the live record into a cited summary, timeline, root-cause analysis, and prevention recommendations.
Which of these it does, and in what order, depends on the incident. A Worker that arrives to find the root cause already known spends its time on impact and verification instead.
## Working with the team
A Worker behaves the way a good teammate would. Messages, threads, reactions, and — where configured — live incident-call transcripts all become context as they arrive. It grounds every substantive conclusion in evidence with citations you can check, threads its findings so the main channel stays for updates the whole room needs, and errs toward silence rather than reacting to chatter. Mention Traversal or reply in a thread whenever you want a deeper investigation, a clarification, or an update.
When you're pulled in late, its [scratchpad](/using-traversal/worker-features#scratchpad) is the fastest way back up to speed — an up-to-date synthesis of impact, conclusions, mitigation progress, remaining risk, and the evidence behind each, so you can skip the scrollback. Follow up in [private chat](/using-traversal/worker-features#private-chat) without any of it reaching the response channel.
[Schedules](/using-traversal/worker-features#schedules) are worth reaching for during an incident — *"recheck the error rate in 15 minutes and post only if recovery stalls."* The Worker comes back on its own, so nobody has to remember to look again once attention moves on.
## When the incident resolves
A Worker stays in sync the whole way through, so it knows when it's over — and it verifies that against live telemetry rather than taking a deployed fix as proof. Once the room reaches consensus it posts a draft [post-mortem](/using-traversal/post-mortems), reconciling its own investigation with everything the team said and did, and says plainly why it's posting.
It also assesses its own work — what it got right, where it was slow or wrong — and recommends ways to improve your alerting so the next incident like this is caught earlier, or avoided altogether.
See [Post-mortems](/using-traversal/post-mortems) for more detail.
## Staying in control
A Worker investigates, explains, and recommends. It never changes your alerting, paging, or routing, and it does not take destructive action. You can [stop proactive mode](/using-traversal/worker-features#stop-a-worker) at any time — you can still mention `@Traversal` with a question afterwards — or give it [custom instructions](/using-traversal/worker-features#custom-instructions) telling it where to look first, what to prioritize, or who to tag.
## Deploy an Incident Worker
Most teams use an [auto-deploy rule](/using-traversal/workers-console#auto-deploy-to-future-channels): point it at your incident channel convention — names starting with `inci-`, `sev-`, or `incident-` — and every future matching channel gets a Worker automatically. You can also [scan your workspace](/using-traversal/workers-console#scan-your-workspace) for recommendations, or [deploy to a specific channel](/using-traversal/workers-console#deploy-to-a-channel).