Skip to main content
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.

By the time responders are pulled in, the first investigation is already done — the deploy and the host ruled out, and a real hypothesis on the table.

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

The Worker stops a failover that would have extended the outage, then picks up a teammate's offhand detail and turns it into the leading path.

​
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 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 without any of it reaching the response channel.
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, 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.

The Worker verifies recovery against live telemetry before it calls the incident closed — then posts the post-mortem in a thread, with a summary, 5 Whys, and an honest account of what it got right and what it missed.

See 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 at any time — you can still mention @Traversal with a question afterwards — or give it 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: 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 for recommendations, or deploy to a specific channel.