> ## 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.
# Alert Workers
> A proactive AI SRE for your alert channels — a verdict on every alert, the reasoning behind it, and the noise cut down.
Alert channels rarely get the attention they need. Engineers either tune them out and miss the warning that mattered, or spend hours keeping up and still miss things. Almost nobody finds time to prune the noisy ones, so the channel only gets louder.
An **Alert Worker** triages and prioritizes every single alert so that you don't have to, and escalates the ones you should actually focus on.
Alert Workers are in **public beta**. Contact your Traversal representative to gain access.
## What happens when an alert fires
Every time an alert fires, the Worker looks at it, investigates, and replies in that alert's thread with what it found and what it recommends. It also reacts to the alert with its assessment, so you can scan the channel by urgency and see which alerts are a critical issue, which are technical debt worth addressing at some point, and which are just a noisy alert that needs its definition fixed.
| Verdict | Meaning |
| :--------------------- | :--------------------------------------------------------------------------------------------------------------------- |
| **Address Now** | Active impact on users or the product right now. On-call should act, route it to the owning team, or escalate. |
| **Address Soon** | A real problem with no user-facing impact yet — tech debt, resource pressure, an internal issue. |
| **Alert Needs Update** | The system is healthy and the alert is at fault. Where the data supports it, the Worker names the specific tuning fix. |
Reply in the thread to push back or ask for more detail. Nothing rests on how often an alert fires — a verdict comes from your current telemetry, prior investigations, linked tickets, and whatever your team already said in earlier threads.
Alert channels run at high volume, so a Worker is built to be token-efficient: when a fire clearly repeats something it has already worked out, it says so and links to that earlier work rather than investigating twice.
## The scratchpad
The [scratchpad](/using-traversal/worker-features#scratchpad) is the Worker's up-to-date synthesis of the whole channel, written for the engineer who just came on call: what needs action now, what's recurring and why, the known causes and prior fixes, and where the alerts themselves are worth improving. Open the Worker from the [Workers console](/using-traversal/workers-console) to read it.
Use [private chat](/using-traversal/worker-features#private-chat) for the follow-ups — *why did this fire, is it getting more frequent, did other alerts share the same cause, how should we update this definition* — without adding channel noise.
## Steer it in plain English
Set policy with [custom instructions](/using-traversal/worker-features#custom-instructions) rather than regex or a rules file:
```text theme={null}
Only escalate Sev1 and Sev2 alerts. Ignore staging unless it affects a customer test.
Always run a fresh investigation for payments-api, and tag the payments on-call
when an alert affects checkout.
```
[Schedules](/using-traversal/worker-features#schedules) cover shift handoffs and alert-health reviews. Because the Worker has been in the channel the whole time, a handoff is what actually happened and what's still open — not a digest of subject lines.
## FAQ
Noise filters mostly count how often an alert fires. An Alert Worker investigates *why* it fired and grounds its verdict in real evidence — your telemetry, past investigations, linked tickets, and what your team already said about it in the thread. Most alerts aren't meaningless noise; they're real problems, unknowns, or misconfigured rules, and the Worker tells them apart.
No. An Alert Worker triages and explains — it posts its reasoning and suggests fixes. It never changes your alerting, paging, or routing. You stay in control of what happens next.
Every response goes in its alert's own thread, never the main channel, so the channel reads exactly as it did before — just with a verdict on each alert. When one monitor double-posts the same fire, the Worker responds once in full and links the duplicates to it.
Yes. Reply with `@Traversal` in the thread to add context and steer the analysis. The Worker will re-investigate when what you've told it changes the picture.