Traversal Workers Are Now Generally Available

Earlier this summer, we introduced Traversal Workers: proactive, superintelligent AI SREs that join an incident channel the moment something breaks, decide for themselves when to engage, and own the investigation end to end. The idea was simple: an AI SRE has to show up where the work is happening, understand the room, and know when to speak and when to stay quiet. It should feel less like a tool you operate and more like a teammate already on the case.

Since launching in public beta on June 30, Workers have run across hundreds of real incidents at some of the largest enterprises in the world, helping teams close incidents faster, pull fewer people into the room, and often find the root cause before the full response team is even paged. It's the strongest response we've had to anything we've shipped.

Today, Incident Workers are generally available and becoming the default incident experience. Alert Workers, now in public beta, continuously triage noisy alert channels. And the new Workers console gives teams one place to deploy and manage their fleet, see what it's done, and start shared Worker sessions directly from the web. Workers run natively in Slack and Microsoft Teams, with no prompting or configuration required.

Incident Workers are now the default

An Incident Worker is a proactive AI SRE that lives alongside your team and acts with agency: it decides when to engage and when to stay quiet, joins the moment an incident fires, and owns the investigation end to end.

Under the hood, a Worker runs on Traversal's Causal Search Engine™ and Production World Model™, delivering the same depth and accuracy that powers all of Traversal. The difference is how that intelligence shows up: in the channel alongside your team, holding the entire system in context, never tiring, and acting at machine speed. It errs toward silence, speaking up only when it has something worth the room's attention. There's no way to use it wrong. It just works.

Meet Alert Workers

Fixing incidents fast is only half the job. Just as important—and a core part of being on call—is catching problems before they escalate into incidents at all.

Now in public beta, Alert Workers bring the power of Traversal's Alert Intelligence to a Worker's form factor. Drop one into an alert channel and it just works, modeling what's normal, causally reasoning across signals, deduping alerts, and surfacing the handful of alerts that are genuinely novel with the reasoning already attached.

There's nothing to configure. If you want to steer it, you do it in plain English. For example: "only page me on Sev1 and Sev2," "ignore anything from staging," "always tag the payments on-call if it mentions payments-api." No regex, no rules file, no engineer in the loop.

This is how you shift left: fewer false pages, faster detection, and more incidents avoided entirely. It's the difference between improving MTTR and improving MTTD, uptime, and the SLOs you're actually measured on.

A web UI for the whole fleet—and every Worker

As teams run more Workers, the job shifts. Engineers become managers of a fleet of agents, and they need a web UI that shows both the fleet as a whole and the work of any individual Worker in detail.

The Workers console is the fleet view. See every Worker across every channel at a glance, pin the ones you always want in view, and use each Worker's status to tell—without opening Slack or Microsoft Teams—whether anything warrants your attention.

From the console, open any Worker to enter its detailed Worker view, with two capabilities you can't get from Slack or Microsoft Teams alone: a live scratchpad and private chat.

The scratchpad is the agent's working synthesis of its channel, helping you see the forest from the trees. For incidents, it gets new responders up to speed and evolves into the postmortem. For alerts, it shows what matters now and the patterns emerging over time.

You can also privately ask the Worker questions without adding channel noise, whether you're investigating alerts on call or catching up after joining an incident.

When there isn't a Slack or Teams channel, you can start a shared Worker session directly from the web. Together, the console and detailed view let you manage the fleet and understand the work of any individual Worker.

Where this is going

Workers get more powerful together. Because a Worker already holds its channel in context, the natural next step is letting them share it, with every Alert Worker making your Incident Workers sharper, and cross-channel causal reasoning surfacing the link between a quiet alert last night and the outage this morning. That's the direction we're building toward: less time spent figuring out what happened, and more of production driving itself

Available today

Traversal Incident Workers are generally available today, while Alert Workers are available in public beta. If you want an agent that stays for the whole incident instead of handing you a report and leaving—and cuts your alert noise while it's at it, book a demo.

FAQ

FAQ

What exactly is launching?

Three things, together: (1) Incident Workers graduate from beta to general availability and become the default incident experience; (2) Alert Workers enter public beta, bringing the Worker primitive to alert channels to replace manual triage and rule-tuning; and (3) the Workers console, a web surface for deploying, managing, and measuring your Workers. They ship as one release because they're one product with two opinionated modes — selected in the web console — and one place to run the fleet. Workers run natively in both Slack and Microsoft Teams. New with this release, you can also start a Worker session directly from the web when there's no channel for it.

What's the difference between an Incident Worker and an Alert Worker?

They are two modes you select in the web console, each with prompts and an experience tailored to a different on-call workflow. An Incident Worker is optimized for a single, focused issue that may run for hours or a few days. It goes deep on that investigation, prioritizing accuracy and MTTR. Its scratchpad is designed to help someone joining midway through the incident get up to speed immediately, then evolves into the postmortem as the investigation progresses. An Alert Worker is optimized for a high-volume channel that may never really end. It is designed to be more token-efficient, intelligently reusing work from earlier investigations instead of starting from scratch each time — including relevant threads where Traversal or the team has already debugged a recurring issue. Its responses are structured so an on-call engineer can quickly scan the channel, gauge the urgency of each alert, and jump into the threads that need attention. Its scratchpad provides a current view of what matters now while also surfacing patterns across alerts over time. Both run on the same underlying Worker platform, but we're opinionated about the experience each use case requires.

Won't another bot just add noise during a Sev1?

This was the failure mode we refused to ship. A Worker errs toward silence and speaks up only when it has something worth the room's attention. It can tell the difference because every judgment about whether to interject rests on a real investigation running underneath. In a high-severity incident, a mistimed message sends engineers down the wrong path and adds real minutes and dollars to an outage; getting the interaction right matters as much as getting the answer right, and that's where much of the engineering went.

How are Traversal Workers different from other AI SRE agents?

Traversal Workers are different in two ways. First, autonomy: a Worker decides for itself when to act and when to stay quiet. It isn't a copilot you have to summon or a rule you configure in advance. Second, depth: every Worker runs on Traversal's Causal Search Engine™ and Production World Model™, so it can carry out a real investigation rather than simply wrap a chat interface around your telemetry. Workers operate where your team already works — in Slack and Microsoft Teams — while the Workers console gives you a companion surface for deploying and managing the fleet.

How are Workers different from the Traversal experience before Workers?

The underlying intelligence is the same, but the Slack and Microsoft Teams experience is fundamentally different. Before Workers, Traversal responded when someone asked a question or when an automation fired on a predefined trigger, such as a specific alert or a new incident channel. Workers are proactive: they continuously listen and manage context even when they stay quiet, deciding for themselves when to investigate and when to speak up. Because a Worker maintains that context and intelligently reuses work it has already done, it can often deliver an answer in seconds instead of starting every investigation from scratch. The new Workers web UI adds another layer: a console for managing the fleet and a detailed view for inspecting each Worker's scratchpad or asking it questions privately.

The gap between "something is wrong" and "we know what is wrong" is where MTTR is won or lost.
NAME
Member of Technical Staff
“99.9% of API checkout requests over a rolling 28-day window return a successful status under 300 ms.”
“99.9% of API checkout requests over a rolling 28-day window return a successful status under 300 ms.”
Lyndon Vickrey
Member of Technical Staff
Escalating to the right owner takes time, and each handoff resets part of the investigation.
Suhaib Zaheer
SVP & GM of Managed Hosting, Cloudways
Learn More

Some similar reads

×

See Traversal in action

Get a live walkthrough of how Traversal finds root cause and remediates incidents in minutes, not hours.

Book a Demo